Goals for muban-router

[ThaNarie]

Before starting main development, it's probably a good idea to outline some of the goals / purposes of this module.

Since the core of muban uses HTML that is rendered on the server, there wouldn't be much need for routing in muban. Each navigation is a normal a-href, that navigates to a new page, that is again rendered on the server.

However, there are a few situations where having some kind of routing logic could be useful;

1. During development or statically generated builds
2. For small sections of a page that require some client-side navigation
3. To manage page-transitions in a "SPA-takeover" mode

Let's explore each of them to see what they would be doing.

1. During development or statically generated builds

The muban-skeleton "fakes" a server by rendering the HTML pages and performing page routing, but only during development. Similarly, when generating a static build, these pages are all rendered out once as if they were created on the server.

It could be argued that this part should not be part of the "client facing" router module, but rather be a separate module purely meant for the "tooling" part of muban. Based on the refinement below, and the feedback in this thread, we could decide to indeed keep them separated.

Since this all takes part on the server when rendering templates, the features and API will most likely only touch those parts; the build scripts and the template functions.

Some ideas;

• Providing access to all routing information
• For each route object, a slug and a route value. Where the route can contain parameter placeholders to build up dynamic urls
• A link template component that can make use of util functions that generate full hrefs based on route definitions and parameters.
• Access to information like isActive if a certain route is active on the currently rendered page
• A way to provide this information to template functions. And a way to pass them down to nested component template functions.

2. For small sections of a page that require some client-side navigation

Even though normally all rendering and navigation happens on the server, there are still situations where client-side routing could be beneficial;

• Small sections that are purely managed on the client (like multi-step forms or tab content), that would still benefit from deeplinking or back button navigation.
• Navigation that happens on the client, but should update the URL to show the same content on a reload or deeplink, like complex forms with search and filters that work with XHR to speed things up on the page, but could still be loaded from the server with the same parameters.

Some of these might be localized within a single component / section, so might only require a "local" router instance.

Others might only be relevant on the client, where this "local" route instance could be configured to use hash routing.

As soon as a "link" doesn't do a page load, but instead executes internal logic on the client, it might be partly overlapping with the dev/build part of the first "use case" (i.e. an isActive state based on the current route, or custom link building).

When incorporating routing in your components, the "state" suddenly moves from the component to the URL, so that should be taken into account when defining the router API.

3. To manage page-transitions in a "SPA-takeover" mode

Normal muban projects have pages rendered on the server, and navigation will just navigate and load a new page from the server. This "transition" between pages is just that, a hard switch.

There are efforts going on to instead of navigating to a new page, it will load new pages through XHR, and then replaces the DOM without doing a full page load. Managing the DOM updates within JavaScript – having access to both the old and the new page DOM – allows for nice page transitions. This could be a simple "fade out", or something more fancy.

To "hijack" this navigation process (click on a link, load a new page, animate out, animate in) we need something that manages everything for us. At the heart of this will live components like a router (that know about urls, what to load when, updating the URL accordingly, handling the back button, etc) and a "link component" (that block the href navigation and instead handle things internally, or knows if a certain link is active).

Next steps

• Coming up with a clear definition of what a "router library" will do, based on the info above
• Start prototyping

[psimk]

Coming up with a clear definition of what a "router library" will do, based on the info above

I think we can do this, while building a prototype for 2. Keeping it as a separate @muban/client-routing library and not worrying too much about server implications. We also already have experience with client side routing, at least from a users perspective:

• react-router
• vue-router

So this seems to be like the most viable first step, then after we have built a prototype and have gained experience with implementing routing, we can worry about 1 and 3.

[MickJasker]

I think it's easier to start on 3 first because then you are only updating one chunk of the page while with 2 you are kind of working with nested routes. I suggest creating a prototype of a router with one router-view with associated guards. When we master that we can worry about nested routes.

[pigeonfresh]

I came across barba which I shared in the frontend channel and @psimk recommended me sharing it in this thread. I haven't done any testing yet. I might spend some time this week on that.