Has anybody implemented an approximation of Route prefetching in Next.js in their elm app (mostly likely through fetching data from backend ahead of time in a per page data cache)?
How do people feel about a per page data cache versus a cache of graphql responses across all pages keyed by graphql request versus a cache of normalized entity data keyed by entity id?
I like the per page data cache, because it seems simple to maintain and ensure cache hits, but I haven’t made up my mind yet.
In my case, I am not interested in build time rendered or server rendered pages exactly, as the data will be dynamic per user, but something loosely inspired by prefetching of rendered pages.
Yes, elm-pages v2 and v3 both do prefetching of the route data on hover Uses the same strategy as NextJS (adds a preload tag so the browser can preload the data).
For what it’s worth, server-rendered pages are great for handling dynamic user-specific data. You’re welcome to choose your own preference of your favorite stack of course, but just wanted to clarify that the server-rendering strategy is designed to work with this kind of use case (elm-pages v3 can do server-rendered routes).
You can also handle routes on the server-side at request-time. The tradeoff is that rather than servering HTML and JSON files from the build step, your server will need to build the page when the user requests it.
I am a little confused on what it would produce exactly? (That is, is the server producing an html page or an html page with an elm app inside or something else? If there is an elm app inside how does it connect with the overall elm app?)
If you’re familiar with NextJS, it works just like that! elm-pages v3 (which is still in a pre-release phase at the moment) resolves data on the server and then passes that to the client. Under the hood it’s running two Elm apps, one that executes on a server to resolve data and server-render the initial HTML, and then one that hydrates in the browser. I’ll be sharing more about it in the coming weeks, but here’s an example you look at. This is TodoMVC but adapted to be full-stack. The app runs all of the DB persistence and manages login using magic link auth with cookie-based sessions.