* chore: dont use prebuilt builder pattern for configuring desktop
* chore: use regular config pattern for web
* Chore: update docs too
* chore: clean up some warnings
* feat: use synchronous router design
* feat: function to get router out of dom
* chore: restructure workspace to use renderers as packages, not features
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.
Jonathan Kelley