Make Route components contribute their path contextually, like Router components

[webJose]

Motivation

Currently, when a Route component is declared to be a match, the matching path is not implicitly available for inner routers or routes. In other words: Even though we can confidently state that the URL is there (because the route matched), one has to repeat the path segments that we know already matched in routers or routes that are found in the matched Route component's children. This seems to be redundant work for the developer.

An example:

<Router basePath={import.meta.ENV.BASE_URL}>
  <Route path="/admin" and={isAdmin()}>
    <!-- The internal admin router:  Must repeat the path (/admin) -->
    <Router id="redundant" path="/admin">
      ...
    </Router>
    <!-- Much nicer would be to simply type: -->
    <Router id="inheriting">
      ...
    </Router>
  </Route>
</Router>

Technical Requirements

1. Currently, the RouterEngine class takes care of path inheritance. It needs to be decoupled.
2. The decoupled solution must be available through Svelte's context mechanism.
3. Only Route components with a string path property value can automagically contribute.
4. Route components without path cannot contribute.
5. Route components with a rest parameter will contribute excluding the rest of the path.

As bonus, Route components that have its path specified via a regular expression should accept a path provider property that accepts a function that returns the path to be contributed contextually. Something like this, perhaps:

<script lang="ts">
  function calculatePathContext(routeCtx: TypeToBeDefined) {
    return `${routeCtx.basePath}/users/${routeCtx.params.userId}`
  }
</script>

<Route path={/users\/(?<userId>\d+)/i} pathCtx={calculatePathContext}>...</Route>

Basically, allow a function to provide a calculation of the path segments to be contributed.

If this bonus is added, then the technical requirement would be to always use pathCtx if provided, and otherwise fall back to the requirements listed above.

[webJose]

Ok, to continue with this, a very important question needs to be answered, and I don't currently hold an answer for it:

How do I obtain the proper IPathProvider (or whatever interface name ends up in code) starting at any arbitrary RouterEngine instance?

In short: I think the architecture of the application needs to change/evolve to support this idea. Remember that, as it is now, the library accepts router and routes as components or code. Both are 100% possible, and mixing them is possible. I'd would say this is something that must be respected and kept.

My first initial thought is creating a RoutePathProvider class for every route definition, and the Route component can take care of the details, but then how does that work when adding routes in code? Consumers of the library would have to create these "by hand" for every route. I am thinking this is very bad DX, so I'm currently ruling it out.

Then there's the freedom the library exposes: Routers and routes can contain more routes and routers, so by the time we want to match to the current location's URL: How can we obtain the proper chain (or final, accumulative) IPathProvider object for each route?

If anyone would like to discuss proposals, feel free to comment. I'm parking this one ATM.