Suggestion: "exact" matching mode

[mbleigh]

It seems like it would be nice to have an exact boolean attribute that would exclude tail matching and require that the whole URL matches the remaining path. For instance, if I have a list and show for users I might want something like:

<carbon-route pattern="/users" active="{{listUsers}}" exact route="[[route]]"></carbon-route>
<carbon-route pattern="/users/:id" active="{{showUser}}" tail="{{userParams}}" route="[[route]]"></carbon-route>

Without exact, there is never a circumstance in which the first route is matched but the second isn't.

If I'm misunderstanding the intended way to structure these routes (entirely probable) feel free to show me how I might approach the above in a more as-intended way. 😄

[cdata]

This seems like something that could fall under the umbrella of "solved by inheritance." For example, a user could implement a carbon-route derivative that has stricter matching semantics.

[mbleigh]

Maybe...I tried to dive in and build a simple app structure (the Polymer Starter Kit routes) using carbon-route and I was pretty quickly stymied as to how to differentiate between /users and /users/:name in a simple and declarative fashion.

Might be missing an obvious way to make that work well -- how would you approach it?

[cdata]

We spent very little time designing matching semantics for carbon-route. This was excusable because inheritance can allow us to offer a derived element with better semantics.

That said, in your case you can bind to the active property on the route that matches /users/:name and use that to achieve the differentiation you are looking for. For example, when the route goes from /users/foo to /users, the active property on the carbon-route that matches /users/:name will change to false.

[mbleigh]

Fair enough. If you think inheritance is a better way to go about this, please feel free to close.

[cdata]

@rictic what are your thoughts on this?

[rictic]

IMO we do want the matching syntax to be reasonably flexible by 1.0, especially if it's a common problem (like this is), and the next best alternative isn't great (which I'm not yet totally sold on for this case).

I was chatting in the slack channel with @TimvdLippe who's also been looking into integrating carbon-route and PSK. The solution we went with was that the main page should could be updated to use iron-pages to select between the home, contact, and users pages. The users page would be handled by a custom element that would have further routing inside of itself to differentiate between displaying all users vs a specific user.

I like this because it encourages building modular elements. If it's still awkward with that use case then I think the case is stronger that we should implement a match-end-of-route feature in pattern.

My perspective in a tl;dr: this seems reasonable, but we want to keep the base carbon-route super small and simple, so we'd like to hear more use cases. No matter what we do for pattern syntax and capabilities, we expect others to extend carbon-route with their own matching logic.

[ronnyroeller]

Thanks for the suggested solution approaches!

Just to share my experience: I bumped into the /users vs. /users/:name issue within 10 min after prototyping carbon-route into our application. Although the suggested solutions are all reasonable, I found it a quite demotivating hurdle for adoption the routing elements, considering that the use case feels pretty common.

[ronnyroeller]

The solution we went with was that the main page should could be updated to use iron-pages to select between the home, contact, and users pages. The users page would be handled by a custom element that would have further routing inside of itself to differentiate between displaying all users vs a specific user.
I like this because it encourages building modular elements. If it's still awkward with that use case then I think the case is stronger that we should implement a match-end-of-route feature in pattern.

@rictic - Encouraging modular elements is definitely a good point. But would sub routing work also with neon-animated-pages which, to my knowledge, require to have all pages on the same level?