Static Router Enhancements #1033
thescientist13
started this conversation in
Ideas
Replies: 3 comments
-
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?). |
Beta Was this translation helpful? Give feedback.
0 replies
-
And another one 😞 - #1068 |
Beta Was this translation helpful? Give feedback.
0 replies
-
Wonder if we could apply the new View Transitions API to this? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 afetch
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:
staticRouter
#936#optimization
), when going back, there will be history entry for/docs/configuration/
AND#optimization
, instead of/docs/configuration/#optimization
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
pathname
and thehash
in one go?RouteComponent
, or is the delegation of responsibility good enough?Beta Was this translation helpful? Give feedback.
All reactions