Best explained by looking at the following example:
#[derive(Clone, Debug, Switch)]
pub enum PostsRoute {
#[to = "/{}"]
Id(u64),
#[to = "/?page={}"]
ListPage(u64),
#[to = "/"]
List,
}
#[derive(Clone, Debug, Switch)]
pub enum AppRoute {
#[to = "/posts{*}"]
Posts(PostsRoute),
}
This feels like it should work. In fact, one of the example in yew-router uses this exact pattern (BRoute is used like PostsRoute here).
The route "/posts/?page=5" will still match PostsRoute::List instead of PostsRoute::ListPage(5) because "?page=5" isn't passed down. PostsRoute only ever receives "/".
This is because {*} stops capturing as soon as it sees " #&?=".
This behaviour is certainly desired when capturing simple values like strings but in this case it's rather unfortunate.
I don't have a proposal to offer because there will be significant changes to the router anyway and this issue should be considered in the new design.
Best explained by looking at the following example:
This feels like it should work. In fact, one of the example in yew-router uses this exact pattern (
BRouteis used likePostsRoutehere).The route "/posts/?page=5" will still match
PostsRoute::Listinstead ofPostsRoute::ListPage(5)because "?page=5" isn't passed down.PostsRouteonly ever receives "/".This is because
{*}stops capturing as soon as it sees" #&?=".This behaviour is certainly desired when capturing simple values like strings but in this case it's rather unfortunate.
I don't have a proposal to offer because there will be significant changes to the router anyway and this issue should be considered in the new design.