total rewrite of the router

[TeFiLeDo]

A few months ago I started rewriting the router (as mentioned on Discord), to make it have an API that feels more "rusty". This is the result of that work.

It has:

• A completely new API, that relies more on Rust instead of rsx.
• Over 100 tests
• A rewritten guide
• nested routes
• parameter routes (with a regex-based variant)
• named navigation
• SSR support (and example)

It currently lacks

• [x] listener
• [x] a way to generate sitemaps
• [ ] a Route component (don't know if it's necessary)

Other things I still need to do:

• [x] update the CRM example
• ~update the usage.md file~ I chose to remove the usage.md file instead of updating it, because I don't see the purpose of that file. I think it is much more likely that users will look at the book, API docs or examples. This also removes duplication, and means that now all router examples can easily be tested.

Sorry that I took so long.

[TeFiLeDo]

Does the current router implement the sitemap functionality described in the usage.md file? If so, can somebody point me to its implementation?

[norman784]

Awesome work, looking forward to try it, I already skimmed your code briefly and because you worked some features I want to have (I made a simpler small PR introducing a initial_url that IMHO is easier to use, because involves less boiler plate #510 ).

As for nested routes (not sure which model works better) but I find easier reason about and compose with #509 where you can visualise at quick glance your page structure with nested routes.

Route {
  to: "/blog",
  h1 { "some text" }
  Route {
    to: "/:id",
    p { "some post" }
  }
}

Otherwise I like what I read in this PR.

[TeFiLeDo]

Awesome work, looking forward to try it, I already skimmed your code briefly and because you worked some features I want to have (I made a simpler small PR introducing a initial_url that IMHO is easier to use, because involves less boiler plate #510 ).

Yeah, I'll have a look to see if I can make this similarly easy.

As for nested routes (not sure which model works better) but I find easier reason about and compose with #509 where you can visualise at quick glance your page structure with nested routes.

Route {
  to: "/blog",
  h1 { "some text" }
  Route {
    to: "/:id",
    p { "some post" }
  }
}

The reason I extracted the route definitions from components is to force users to have it all in one place (or at least get it explicitly from somewhere).

When you have a lot of components in several files, and every single one can define new nested routes, it becomes very hard to keep track of all of them.

Otherwise I like what I read in this PR.

Thank you

[norman784]

The reason I extracted the route definitions from components is to force users to have it all in one place (or at least get it explicitly from somewhere).

When you have a lot of components in several files, and every single one can define new nested routes, it becomes very hard to keep track of all of them.

I think, if possible, we should allow the users to use how they want, some will prefer to have them all grouped, others maybe split them, so plug and play a whole set of components could mean add/remove just one route (if you nest them inside another component). That said, I'm not sure how hard is to implement something like this (by reading #509) seems to be possible.

[TeFiLeDo]

If you don't like defining all your routes in one place, you don't have to do that. You can simply create a function that returns one of the route definition types and use it when creating the root segment.

Also the router needs to know about all existing routes upfront. This is important for its ability to detect invalid paths (i.e. 404 not found) and the named navigation feature.

[TeFiLeDo]

Just looked through the open issues a bit:

• #493 AFAIK, none of my examples are ignored
• #432 nested routes work
• #348 WebHashHistory uses the hash instead of the path

[TeFiLeDo]

Awesome work, looking forward to try it, I already skimmed your code briefly and because you worked some features I want to have (I made a simpler small PR introducing a initial_url that IMHO is easier to use, because involves less boiler plate #510 ).

I added an initial_path prop to the Router that should be similarly easy to use as your work in #510. When compared to the original way of using a ControlledHistory, it is a bit limited, as it doesn't allow you to detect redirects. However, it should work perfectly fine for all cases where that isn't important.

[jafioti]

@jkelleyrtp Has there been any action on this? I'd really love to start using dioxus for my website, but the lack of a decent router is a big hurdle.