Suggestion: "exact" matching mode about app-route HOT 8 OPEN

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.

from app-route.

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.

from app-route.

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?

from app-route.

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.

from app-route.

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

from app-route.

@rictic what are your thoughts on this?

from app-route.

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.

from app-route.

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?

from app-route.