Static Router Enhancements

[thescientist13]

Overview

There is currently a staticRouter config option in Greenwood that at build time, creates "content" fragments for all static pages (markdown / HTML) based on the the template of the page. This means, if a user navigates from say one blog post to another blog post, only the content between the <content-outlet></content-outlet> tags swap out, preserving the shell of the page. (Using a fetch call on the client side)
https://github.com/ProjectEvergreen/greenwood/blob/master/packages/cli/src/lib/router.js

You can see this on the current Greenwood site. If you navigate from Docs -> Getting Started you will notice the whole page doesn't reload (like a traditional MPA would). Same goes for visiting any blog post. This is very similar to technologies like Turbolinks and PJax (but without the server component)

As you may have noticed in the docs, this feature is marked as experimental, that is for a few reasons:

1. Greenwood isn't trying to build an entire router, and our focus isn't entirely on this feature, but only because of lack of experience and so issues are bound to pop up. I suppose if we enabled good E2E tests this would mitigate obvious issues that pop up from time to time, but it has just been a YMMV feature, but perhaps we can change that! 🤞
   • hash navigation fails to navigate to correct heading/page with staticRouter #936
   • deeply nested direct hash link breaks the router if pathname not already present #1026
2. Back button navigation is a little funky on first click. Although the history is accurate, the browser doesn't always correctly scroll to the correct position. Also, there is a small bug where if you just expand a link (Docs -> Configuration) and click a hash link (#optimization), when going back, there will be history entry for /docs/configuration/ AND #optimization, instead of /docs/configuration/#optimization
3. Cross browser compatibility support is limited to just Chrome / Edge / FF - make router standards compliant with consistent cross browser support #559

Thoughts

So obviously we would want to address the above cited points, but there are also some enhancements to consider:

Permeate Template Boundaries

Navigate across page templates so a hard page reload isn't needed , keeping things entirely client side once the application is loaded. This would put Greenwood in the classification of "Transitional Apps" as defined by Rich Harris.

Think of the use case where you have a video / music player, and in an MPA style, a new page load would completely reload the page and tear down the player.

SSR (Fragment) Routing

As stated, currently this feature is only supported for markdown / HTML files in the project, not any server rendered routes. So wouldn't it be cool this also worked for SSR routes too? Since Greenwood is based on file based routing, we can probably find a convention where we can map link clicks for either static or server routes, and if it's a server rendered route, fetch it from a live endpoint instead.

The application would then provide a live endpoint for serving fragments which if fronted by a CDN, could also provide full caching capabilities / strategies. This way, a page fragment could either be fetched locally or remotely, and still preserve the continuity of client side routing. 💯

GET /api/fragment?slug={:/slug}

API Routes might make it so we can provide this out of the box and at serverless / at the edge. 👀
#1007

E2E Testing

We should really get some E2E Testing on the website so we can catch bugs like the ones referenced above to better give us confidence that we can mark it as non experimental and also be able to make changes and not worry about breaking something in the process. 🤕

General Refactoring

1. Can push state both the pathname and the hash in one go?

   history.pushState({}, '', `${targetUrl.pathname}${targetUrl.hash}`);

2. Should more more of the logic go into RouteComponent, or is the delegation of responsibility good enough?

[thescientist13]

Another adjacent feature / behavior to this would the idea of pre-fetching routes / fragments either on link hover (which wouldn't work for mobile) or while in viewport (which could over fetch?).

[thescientist13]

And another one 😞 - #1068

[thescientist13]

Wonder if we could apply the new View Transitions API to this?
https://developer.chrome.com/docs/web-platform/view-transitions/