Why are query parameters not supported anymore? about bidi HOT 5 CLOSED

Hi,

For use in CLJS, it would be nice to get the query params. I understand the rationale for not matching the uri pattern based on Q/params, but it should would be nice if it was part of the result of a match parsed into either a list of pairs or a multi-map

from bidi.

For those still looking to get around this on cljs, I ended up doing something like this (using cemerick.url as a dependency to easily parse the query parameters.)

Ideally though, match-route should allow an option to return a map of the query params too!

(defn match-route-with-query-params
  [route path & {:as options}]
  (let [query-params (->> (:query (cemerick.url/url path))
                          (map (fn [[k v]] [(keyword k) v]))
                          (into {}))]
    (-> (bidi/match-route* route path options)
        (assoc :query-params query-params))))

from bidi.

Thanks. I agree with your rationale. My usecase is that I use bidi client side. There I don't have ring available. Obviously, I can and will just port the two necessary functions for parsing and emitting query strings, to have them available in individual handlers and build routes with them. Taking different dispatch routes based on them is obviously a bad idea, but that is also not what I was asking for :)

from bidi.

The query parameter routing was removed because it added quite a lot of complexity, which was compounded by the need to support both clojure and clojurescript targets. Query parameters are still passed in to handlers via the Ring request, as normal.

The bidi.ring/make-handler function uses the :uri of the request, which doesn't contain the query string. The query string will still be available in the :query-string entry of the request, which you can parse into a map if necessary with ring.middleware.params/params-request

You shouldn't ever need to dispatch to different handlers based on the query-params. Query parameters are intended as extra parameters to pass to the handler, not to distinguish between handlers. When you form routes with path-for you should create the path, then manually append your query-string if necessary.

But please let me know if this advice doesn't help you, and expand on your use-case in more detail. There could be other options to achieve what you need to do, and I'm very happy to support this in bidi directly if necessary. I just don't want to add special cases to bidi that encourage unintended uses of query parameters.

from bidi.

I also face the same issue with a reagent frontend app. The issue is that when you change the routing state (in other words, not change the url, but the other way around), then there are some handlers that need to know query params. So in cases like that, te bidirectional capacity of bidi breaks down.

from bidi.