Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better explanation on what Routify does wrt preload & rehydrating #174

Open
tv42 opened this issue Aug 12, 2020 · 1 comment
Open

Better explanation on what Routify does wrt preload & rehydrating #174

tv42 opened this issue Aug 12, 2020 · 1 comment

Comments

@tv42
Copy link

tv42 commented Aug 12, 2020

I understand Routify started out as a SPA router, and a bunch of rollup config+plugins and/or Roxi can make it be more. But since the "more" part is actually also part of the routify script (e.g. export), it gets confusing. This could be explained clearer, with an overview of the ecosystem around Routify and drawing boundaries on part what does what. My understanding is something like:

routify export uses https://github.com/roxiness/ssr as library to write out static HTML for all static routed (no parameters) pages. Web server configuration must deal with dynamic pages, serving (what page? /__app.html?) for them, making them get the "just a SPA" experience.

(Tangent: calling the web server internal URL dispatching "redirect" can be misleading. I think I've seen that all over the website.)

Spassr https://github.com/roxiness/spassr is a web server that does on-the-fly
server-side rendering using the same logic, with later navigation
handled by the progressive SPA. Spassr seems utterly undocumented as
of 2020-08.

To detect whether you're running on server or client, use something like navigator.userAgent.match('jsdom'). Not sure if there's a way to transfer state from server to client neatly? If I fetch something from a backend and assign to local let foo variables, is that transferred to the client, or re-fetched by the browser when it renders things? If it is transferred directly, talk about limitations: can I only assign JSONable data to let foo?

See discussion at

Other ecosystem parts around routify (where it differs from plain Svelte or Sapper):

@jakobrosenberg
Copy link
Member

I understand Routify started out as a SPA router, and a bunch of rollup config+plugins and/or Roxi can make it be more. But since the "more" part is actually also part of the routify script (e.g. export), it gets confusing. This could be explained clearer, with an overview of the ecosystem around Routify and drawing boundaries on part what does what. My understanding is something like:

routify export uses https://github.com/roxiness/ssr as library to write out static HTML for all static routed (no parameters) pages. Web server configuration must deal with dynamic pages, serving (what page? /__app.html?) for them, making them get the "just a SPA" experience.

This is correct, though we provide serverless functions for Vercel and Netlify to handle realtime SSR as well as spassr which is a small express server that serves SPA as SSR.

(Tangent: calling the web server internal URL dispatching "redirect" can be misleading. I think I've seen that all over the website.)

Could you expand on this? I'll admit naming is what we struggle with the most. 😅

To detect whether you're running on server or client, use something like navigator.userAgent.match('jsdom'). Not sure if there's a way to transfer state from server to client neatly? If I fetch something from a backend and assign to local let foo variables, is that transferred to the client, or re-fetched by the browser when it renders things? If it is transferred directly, talk about limitations: can I only assign JSONable data to let foo?

Unless you disable javascript and rely on exporting pure HTML, pages will be rehydrated. Another way to avoid rehydration is to use transform in your bundler.

Roxi might provide a bit more flexibility when it comes to hydration, but there are a lot of gotcha's involved. Especially when it comes to PWA/offline first functionality. I'm very open to ideas on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants