PolymerElements
Suggestion: "exact" matching mode
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. :smile:
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.
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?
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.
Fair enough. If you think inheritance is a better way to go about this, please feel free to close.
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.
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.
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?