Route.match' edge case question

[john-kelly]

Route.match' edge case question

[john-kelly]

thanks so much for chatting about this!

[anuragsoni]

Hello! Thank you for taking a look at this library!

is the current behavior expected? if not, i think the issue is here:

The current behavior is indeed expect (I admit I haven't done the best job at documenting this 😅). When writing the route matching my thinking was that having the same node act as both an exact match, and a capture (like in your example) would be a little confusing, and make it harder to predict how route matching is supposed to work. The current implementation seems easier to reason about for me personally. Performance wasn't the reason for making this choice, but reducing some backtracking does help I guess :)

I have thought about being stricter at times by not allowing patterns where an exact match and a capture happens on the same node at-all. That reduces some flexibility, but it makes things a little easier to understand as users if there's an actual error/feedback at the time of creating the router, instead of silently missing a route like you see here.

[anuragsoni]

Excellent writeup about elm/url! While not quite the same, the first version of routes (https://github.com/anuragsoni/routes/blob/0.1.0/src/routes.ml) was closer in spirit to elm/url's parser than where I've ended up today!

[john-kelly]

Thanks for the quick response! Your answer makes sense to me. I agree it’s easier to reason about.

I have thought about being stricter at times by not allowing patterns where an exact match and a capture happens on the same node at-all.

How would this be achieved? Would add return an option/result?

Edit: Oh i guess ocaml has runtime errors! so would you just throw? elm doesn’t so i had not even considered that as an option.

[anuragsoni]

How would this be achieved? Would add return an option/result?

Since we can perform this check at the time we create a router instance, and when adding a new route to an existing router, we can have these functions return a result type that make it clear that this operation can result in errors. Adding an exception raising variant of these functions could also be nice in-case people would like to fail with an exception early on in the app lifecycle.