You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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 locallet 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 tolet foo
?See discussion at
onMount
blocks during SSR routify#165 (comment)onMount
blocks during SSR routify#165 (comment)Other ecosystem parts around routify (where it differs from plain Svelte or Sapper):
which updates client-side code without refreshing the page
plugin or wrapper for the above?
Replacement feature to Rollup bundling
The text was updated successfully, but these errors were encountered: