Attempting to use filters is unneccesarily inconvenient

[mikroskeem]

(docker/invoke conn
               {:op :ContainerList
                :params {:filters (json/write-value-as-string {:label {const/server-name-label true}})}})

While this makes kind of sense, because...

{:doc
 "List containers\nReturns a list of containers. For details on the format, see [the inspect endpoint](#operation/ContainerInspect).\n\nNote that it uses a different, smaller representation of a container than inspecting a single container. For example,\nthe list of linked containers is not propagated .\n",
 :params
 ({:name "all", :type "boolean"}
  {:name "limit", :type "integer"}
  {:name "size", :type "boolean"}
  {:name "filters", :type "string"})}

... filters is string, but maybe this could be handled differently?

[lispyclouds]

Hey @mikroskeem

Thanks for raising this issue and this is a valid one as filters are something that are used often.

The idea was to keep the client as simple as possible and not put layers in between the user and docker, cases like this warrant some form of translation. Some of the ideas I can think of the top of my head:

• Have an interceptor/middleware like thing for the requests which transform values before sending and after receiving
• Have provisons of passing custom updater/transformer fns to invoke when calling
• Supply helpers (this is something I'm not in favor of as this makes the lib carry opinions which may not be useful to all)

I would like to know what you would think of as a nice solution to this? I am totally open to any suggestions and would really wanna make this even more approachable and useful 😄

[mikroskeem]

Supplying helpers is not very great idea indeed, with the reason you pointed out. I'd rule that option out completely.

First two are okay, perhaps 2nd one is the easiest to implement currently and would be sufficient. But I'd like to look into the first option as well. How would that look like?

[lispyclouds]

I could imagine interceptors to be something like this using a lib like sieppari:

(def filter-interceptor
  {:enter (fn [ctx]
            (update-in ctx [:request :params :filter] json/write-value-as-string))})

then something like

(sieppari/execute
  [filter-interceptor ..other-interceptors http-handler]
  {:op ... :params ... :as ...})

this way im thinking it would be a nice way for people to plug in their custom transformers without too much internal exposure.

Having said that, I'm finding it hard to find time unfortunatey 😞 Will try to make time for this and if possible happy to swiftly merge PRs!!