v2.0 Architecture

[webJose]

Thinking about the limitations that v1 carries when trying to fulfill #30, I have realized that, in this particular case for this particular library it might be a good idea to get rid of the "router" concept.

Since this library will simultaneously match any number of routes if their conditions are met, I wonder if the "router" concept is needed at all. After all, the router's main job is to centralize routing. But for what purpose? Most other routers do this to ensure only one route matches, or at least this is what I believe they do. Since this library is not doing this, why keep the router around?

Proposal

1. Eliminate the Router component and the RouterEngine class.
2. Create a RouteEngine class with the route-matching logic.
3. Create a new RoutingContext component to collect route-matching together and enable fallback content.
4. Have routes propagate basePath, plus any additional matched segments from parent routes (to fulfill Make Route components contribute their path contextually, like Router components #30).

Explained in words: Migrate the route-matching logic to the route itself, then have routes report route matching status to RoutingContext. RoutingContext is used to trigger fallback content and to provide route status information via its children snippet for people wanting it. Routes also inherit the router's basePath functionality.

RoutingContext will also be needed to enable DPUI, which might require a separation of the DPUI functionality into a new, simpler component where we only specify the route's key. All route matching logic is omitted.

Up to this point, RoutingContext can be optional. Only add if fallback content or DPUI is needed, or if we want/need centralized route-matching data collection.

Potential Problems

RouterTrace needs to be completely reinvented. I suppose it will have to trace routing contexts instead, but its router traversal feature is a goner. Will an extra RouteTrace component be needed to traverse the routing hierarchy? I'm not envisioning how these would look like.

Creating routes via JavaScript will become more complex. Routes will no longer be just data that lives in the router's state since there will be no router. Furthermore, creating a route in code will still require a markup counterpart.

[webJose]

The potential resolve() function would require a RoutingContext instance.

[webJose]

Shoot, ok. Since this affects DPUI, I'm now unsure if this is even a good proposal.

[webJose]

RoutingContext

Reactive class and component that collects the matching status of all routes within its children. Required for the Link's active feature, fallback content and DPUI.

HierarchicalContext

Reactive class that, for now, only aids with inheritance of basePath. The only provider would be Route components and their contribution would be as detailed in #30.

Consequences

• The key property of routes can be made optional. If specified, it can participate in routing contexts; if not, then it is invisible: Not available for fallback determination, and not available for the Link's active feature.
• RouterTrace's implementation becomes much more difficult. We no longer have detailed route information (like the generated regular expression) readily available in one place. It might be the end for this debugging component.
• Adding dynamic routes via JavaScript gets a bit more complex. Unsure about its shape right now. In v1, we create RouterEngine instances. These instances fully work even if not associated with anything in the markup. They work. They calculate route matching status information immediately as routes come and go. To get routes to work immediately without markup, they would require to be represented as RouteEngine instances, I suppose. But routes without a place to render are useless. Meaning? Only way to add dynamic routes is by adding Route components in markup. Are we OK with this?