Nested routers for path segment matching

[Banyc]

yew-router now only support absolute path matching, which forces pages of different domains to aware their absolute paths in the project.

React router defines each route with a path segment, so that however the upper routes change, the sub-routes don't need to change anything.

I tried implementing the core logic of path segment matching, which wraps route-recognizer. It not yet becomes components in yew, but I feel like it is implementable theoretically. I'll try make a prototype yew router lib that supports path segment matching. The code gen part at derive is a bit challenging for me so I'll just skip it.

References:

• React router: https://reactrouter.com/en/dev/start/overview
• Path segment matching routers: https://github.com/Banyc/nested_router

[Banyc]

Don't know why but example/ in https://github.com/Banyc/yew-router-2 just doesn't compile.

[Banyc]

Please help! 🥺

[futursolo]

The master version of Yew has an IntoPropValue implementation that allows converting closures to yew::Callback implicitly upon receiving it as a prop. However the repository is using Yew 0.19 which does not have this trait implementation.

The following should work:

#[function_component(Main)]
fn app() -> Html {
    let routes = routes();
    let pathname = use_location().unwrap().path().to_owned();

    html! {
        <BrowserRouter>
            <Switch
                routes={routes}
                render={yew_router::switch::Callback::from(switch)}
                pathname={pathname}
            />
        </BrowserRouter>
    }
}

[Banyc]

The prototype router is working now! https://github.com/Banyc/yew-router-2. The repo contains two examples. One is for the basic routing. The other is to explain how the nested routers work.

[Banyc]

Remove Cargo.lock to upgrade the nested_router crate.

[hamza1311]

Thanks for the working on the prototype. I looked around the code and got a couple of comments:

• It looks like the router is stringly typed (routes are strings, not an enum). That isn't something that should be added to yew-router. In fact, with the yew-router rewrite, I did initially start with stringly typed API but later decided it's not s good idea and reworked it to use enums
• Also, have you looked at the matchit crate? It may be helpful here. I don't know if it can be used for nested routing though.
• I would prefer to have the nested_router crate that you created be part of route-recognizer. That way everyone can benefit from the work you have done.

[Banyc]

Thanks for the suggestions! You definitely have taken time to browse my code. Thanks for the time you spent on my code! I'm so appreciated!

1. _
   • Drawbacks on string: Yes, stringly typed is not better than enum because string is like hard-coding when spamming "the strings". But this drawback might be alleviated by const SOME_PATH: &'str = "sub"; and use that instead.
   • Drawbacks on enum: I came across a problem to go to a previous path in the original yew-router. The problem is I can't do the return_url trick, need to use the enum instead. But the return_url should understand all Routable enums in the web.
2. Thanks for the new knowledge! At the first glance, according to the README.md, it seems not like mentioning the nested routing functionality. It takes time to go through its test code so I might try to get familiar with it later.
3. It's actually a good idea to do a pull request! I haven't thought of it before. But nested_router is basically a wrapper on route-recognizer, having some extra structs, so I might have to think of a way to refactor and insert the logic into route-recognizer.

[hamza1311]

The problem with consts is that they:

• can't be used in match statements. It's possible but very in-ergonomic
• are a pain to use when navigating. Routes::Page { id: value } is much better than format!("{}/{}", PAGE_ROUTE, id)

I came across a problem to go to a previous path in the original yew-router

Can you describe the problem in more detail?

[Banyc]

About the return_url: for example, I want to do a login page. The path parameters of the login page contain a return_url, which is to redirect browser to the return_url page after logging in. The login page is a separate module that should not understand the route enum of any other page.

[futursolo]

You can push an AnyRoute::new(return_url) entry to navigate to any url.

[Banyc]

Thanks! You all solved my actual problem!