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.
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".
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.
This change switches back to the original `ctx<props>` syntax for
commponents. This lets lifetime elision to remove the need to match
exactly which lifetime (props or ctx) gets carried to the output. As
such, `Props` is currently required to be static. It *is* possible to
loosen this restriction, and will be done in the future, though only
through adding metadata about the props through the Props derive
macro. Implementing the IS_STATIC trait is unsafe, so the derive macro
will do it through some heuristics.
For now, this unlocks sharing vnodes from parents to children, enabling
pass-thru components, fragments, portals, etc.