-
-
Notifications
You must be signed in to change notification settings - Fork 913
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A partial implementation of the router and associated bits #107
A partial implementation of the router and associated bits #107
Conversation
e6722c5
to
7732ddc
Compare
Thank you!! |
9ded513
to
fa9d082
Compare
Done. |
fa9d082
to
f526c7d
Compare
Every element can have a title, but it's particularly useful on links, so I think making it an explicit option is worthwhile.
This was "registerd_routes", missing an "e".
I was trying to debug some issues with my routes and this additional tracing was quite helpful.
There are a few different changes in here that probably need to be picked apart. I'm sure much of this is wrong. * Fix missing `dyn` that compiler complained about in router.rs * Make UseRoute store a `Rc<RouterService>` rather than a string so we can get information out of the router like current location. * Implement `UseRoute`'s nth_segment and last_segment methods. I changed the return type to a String because of the above. * Remove some unused imports in platform/mod.rs and service.rs * Implement the `use_route` fn. It panics if called outside a Router { } (I think). I think that makes sense. * Add a `current_location` method to `RouterService` that returns the current location. I needed this both for the `UseRoute` implementation and _also_ so I could get at this in my webapp code. I think having some way to get this will be useful for others, whether or not this exact API is used. In my case, I want to compare the current path to the `to` path of a `Link` so I can use a different class for that `Link` if it is the currently active page.
We don't want to have the router just always match paths as exact strings. If a path contains a parameter like "/thing/:id" then the ":id" portion of the route should match _any_ string, not a literal ":id".
This relies on the RouterService to capture path params when it does path matching.
1a50df7
to
3397a2c
Compare
3397a2c
to
e06eac1
Compare
Previously the router just stored a `root_found` boolean after it picked a route. But on re-render it would just always return false from `should_render` if this was true. This just aborted routing after a future resolved (or anything else that triggered a re-render). Now we store the matching ScopeId and check that against our routes in a re-render so we actually do re-render the matching route.
…_safety Not all components will be mounted when using a Router, so we cannot assume all components have a scope.
Would you like me to review this? Looks pretty functional :) |
Yes, please do. I think there's enough here to at least figure out if this is the right design. I can make further changes or I'm happy to have you make commits directly. I can also rebase this as needed. |
d562241
to
6408058
Compare
Since the Router still needs some configuration for desktop support, I'm going to merge this as is and then follow it up with a PR that you can review. Thank you for adding this! It's amazing to have full (almost) router support now! |
No description provided.