Limitations when using same handler for different routes about bidi HOT 5 CLOSED

Hi Ragnar - this is a great feature request.

I hadn't considered this use-case but it's clearly a good thing if bidi continues to find a handler which does match. Obviously there is a determinstic order here, so I think it makes sense that bidi returns the first route that matches, but if there's missing parameters, it shouldn't blow up like it does, but continue seeking a match. Let me think over this for a bit longer and see if a good design occurs to me. I'll leave the issue open.

And please accept my apologies for taking so long to respond.

Regards,

Malcolm

from bidi.

Hi,

I just got into the same situation, these are my routes in question:

(def routes ["/" {""   :index
                  "v/" {[:source-id] {""              :composition
                                      ["/" :track-id] :composition}}

                  "s/" {[:search] :search-results}}])

The track-id is an optional parameter, Bidi is able to match-route fine for both cases, but leaving the code as is the path-for only works without the :track-id (it's always ignored). By inverting the order I can generate with :track-id but trying otherwise will blow up (like discussed before).

Would be great to have this feature.

from bidi.

This code looks like it is intended to solve this problem:
https://github.com/juxt/bidi/blame/335cb3165f873e8590199fcc20acb288104fe7ce/src/bidi/bidi.cljc#L451-L453

451 ;; If you have multiple routes which match the same handler, but need to
452 ;; label them so that you can form the correct URI, wrap the handler in
453 ;; a TaggedMatch.

Just adding a wrapper, e.g., (tag :mytag 'handler) in both the routes and path-for just makes it return nil, however. Can you clarify @malcolmsparks ? Is that code related to this problem? If not, are you open for a pull request?

from bidi.

Actually is should be (tag handler :mytag) - the argument order of the TaggedMatch record was confusing (the tag function was switching the args around). I've cleaned that up in the last commit.

I think this issue, in general, is addressed by the use of tags. If you want the same handler at more than one route, you can use tags to distinguish between them. I'm concerned that an approach which involved path-for continuing it's journey until it had uncovered every possible match would impact performance for everyone.

from bidi.

Sounds good, thank you!

from bidi.