Async/streaming SSR renderer #958

Rich-Harris · 2017-11-25T22:41:00Z

Now that we have an await template primitive, it makes sense to have a streaming renderer:

require('svelte/ssr/register');
const app = express();

const SomeRoute = require('./components/SomeRoute.html');

app.get('/some-route', (req, res) => {
  SomeRoute.renderToStream({
    foo: getPromiseSomehow(req.params.foo)
  }).pipe(res);
});

It would write all the markup to the stream until it encountered an await block (at which point it would await the promise, and render the then or catch block as appropriate) or a component (at which point it would pipe the result of childComponent.renderToStream(...) into the main stream).

We'd get renderAsync for free, just by buffering the stream:

const markup = await MyComponent.renderAsync({...});

Doubtless this is slightly more complicated than I'm making it sound.

The text was updated successfully, but these errors were encountered:

JulienPradet · 2020-01-27T10:13:40Z

Would you consider a PR that would tackle renderAsync that handles {#await} but without the streaming approach ?

The reason I'm suggesting this is because I don't know how to tackle head and css rendering in a streaming context. And a renderAsync would still be useful for Static Site Generators which don't need streaming since everything is done at build time.

Unless you have some pointers/ideas that I could try to implement?

AlbertMarashi · 2020-05-13T01:07:34Z

@Rich-Harris would it be appropriate to have some sort of serverPrefetch() function like VueJS inside components to do async data grabbing and provide state to the component

AlbertMarashi · 2020-05-13T01:08:55Z

@JulienPradet I agree with you, I would prefer something that handles {#await} without the streaming approach.

It wouldn't make sense as components contain their own head and CSS, and you would need to render all components before getting the head + css

AlbertMarashi · 2020-05-13T02:07:46Z

Would it be possible to have some sort of onSSR() hook inside components that are called asynchronously on the serverside, and only available within the renderAsync() function?

This is similar to what Vue does: https://ssr.vuejs.org/api/#serverprefetch & https://ssr.vuejs.org/guide/data.html#data-store

I am looking into how we could better implement SSR & Async data in svelte. We need first-class SSR support if we want enterprises to use this.

AlbertMarashi · 2020-05-13T04:54:47Z

I've helped a bit with Vue's server-side rendering tools, and have thought a bit about SSR and passing data to clients and have a few thoughts that could hopefully be considered

Ideally, all data generated during SSR should be passed to the client, so that the client can have the same state, and stop client-side hydration from failing.

Generally, some sort of global store can make this easy, as the state can be exported as JSON and injected on the client-side (tools like Vuex have .replaceState for hydration). One issue with this is that every component that needs data passed to the client needs to use a store, and can't really use local state. This is not great since you want your component to not rely on external variables

My ideal setup/flow would work something like this:

<script>
let article

// optional preload function called during SSR, available to all components
export async preload({ params }){ 
  article = await getArticle(params)
}
</script>

pseudocode during SSR

// object containing all data for all components, serialized to JSON before sent to client
let hydrationData = {}

I'm not sure about the exact logic and order of operations in svelte, but I imagine something like this

// done for every component
function create_ssr_component() {
   let component = instantiateComponent(Component)
   if (component.preload) { //update
     component.$set(await component.preload())
   }
   hydrationData[component.uniqueID] = component.$capture_state() //server generated unique id
   return await component.renderAsync() // data is captured before HTML string is generated
   //output { html: `<div ssr-id="1">...</div>`, ... }
}

Doing the rendering

let { html, css, head, hydrationData } = await App.renderAsync()
// window variable included inside <head> for client hydration
`<script>window.__hydrationData__ = ${JSON.stringify(hydrationData)}</script>`

on the client

new App({
  target: document.querySelector('#app'),
  hydrationData: window.__hydrationData__,
  hydrate: true
})

On the client-side, the client will try to inject each component's hydrationData as props, matching the server-side generated unique IDs included on every component with the hydrationData, aborting hydration in any subtree where data doesn't make sense

I hope this makes sense @Rich-Harris, I am sure there's many issues with this, but I feel that it could potentially work

Alternatively

Do something similar to vue, expose some sort of serverPrefetch hook on the server side, allow it to receive some sort of $ssrContext, like vue (which may include URL, req/res or params), and allow it to access some global store so state can be transferred to the client-side

Right now

I am relying on <script context="module">, and my router is awaiting the function's result prior to the route-level component being rendered, and exposing it to the prop.

This isn't optimal, as I would like sub-components to have access to asynchronous data loading

<script>
export let test
</script>
<script context="module">
export async function serverPrefetch () {
    return {
        test: await 'foo'
    }
}
</script>

maxcoredev · 2020-10-03T06:04:14Z

Hi everyone, just wanted to share how I deal with it now.

SSR is only for search engines, right?
Then everything we need to stay with App.render is to implement sync fetch and omit async/await syntax while SSR (not a big problem since it is only for search engines based on robots http headers or special GET param).

So, three things needed to make browser and server code act the same:

Make https://www.npmjs.com/package/node-fetch accessable globally so no need to import
Extend it with fake .then() method
Remove async/await syntax using Sveltes preprocess

Server config rollup.config.server.js:

function sync(content) {
	const compiler = require('svelte/compiler');
	return compiler.preprocess(content, {
		markup: ({ content }) => {
			let code = content
				.replace(/\basync\b/g, '')
				.replace(/\bawait\b/g, '');
			return { code };
		}
	});
}
export default {
    ...
	output: {
        ...
		intro: `const fetch = require('sync-fetch');
		        fetch.Response.prototype.then = function(foo) {
		        	return foo(this);
    			}`
	},
	plugins: [
		svelte({
        	...
			preprocess: {
	        	script: ({content}) => sync(content),
			}
		}),
	],
}

Now we can write clear pragmatic code that will produce exact same result on both SSR and browser

Now, this works:

<script>
    let objects = fetch(`http://localhost:8000/api/article/1/`).then(r=>r.json());
</script>

{#await object then object}
    {object.text}
{/await}

This also works:

<script>
    let object;
    (async (page) => {
        objects = await fetch(`http://localhost:8000/api/article/1/`).then(r=>r.json());
    })()
</script>

{object.text}

Does not work, but that's not a disaster: (probably can be easily solved somehow)

<script>
    let object;
    fetch(`http://localhost:8000/api/article/1/`).then(r=>r.json()).then(r=>object=r)
</script>

{object.text}

blairn · 2020-10-03T06:46:23Z

SSR isn't only for search engines.

A lot of the SSR we do is so people who have awful connections can still see our data visualizations while waiting for the rest to load - or if they don't have Javascript.

Rendering a component on the server, and then using that component in the client is very useful. I just wish it was easier to wire it all up.

AlbertMarashi · 2020-10-03T07:01:32Z

SSR can reduce the largest contentful paint, which is also an important UX factor that can affect perceptions of how fast websites load

maxcoredev · 2020-10-03T07:11:52Z

Sry, I am not about SSR in general. Just about case of this thread

roblabla · 2021-07-12T18:00:21Z

I'm trying out svelte/sveltekit in a small app I'm writing, and I'm hoping to query the database from the server during server-side rendering, and am having trouble understanding how I can do that without something similar to the preload function proposed in this comment.

kaushalyap · 2021-09-15T10:43:11Z

@AlbertMarashi What is SSR strategy used in Svelte kit? Does it support streaming?

y0zong · 2022-06-10T09:50:08Z

does this dead cuz it's years still in pending, and I am face this too, how to get render data after promise resolved if we not use sveltekit ?

kryptus36 · 2022-06-11T23:44:21Z

In sveltekit, this seems to have been solved using load()

But for those of us not using sveltekit, is there a way to do it?

Evertt · 2023-07-01T13:11:56Z

@Rich-Harris could we then also get "top-level awaits" in reactive blocks?

<script>
    let name = "john"
    let upper
    $: {
        await sleep(3000)
        upper = name.toUpperCase()
    }
</script>

<input bind:value={name} />

lucidNTR · 2023-11-28T21:49:00Z

adding more context for a usecase where sveltekits load does not help: i figure out what data needs to be loaded by looking at the property acces to stores that the templates do and then generate a query behind the sccene, so it is inherently async. corrently the only two options i have is to render twice once to see what data the template needs and again with the fetchedd data or to push nearly mepty SSR pages to the client and let everything be rendered client side but with streaming /async support i could use this for fully serverside rendering without any boilerplate manually defining what deata is needed.

crisward · 2024-02-10T16:36:41Z

I realise this issue was opened 7 years ago. But I'd love to see this in svelte 5.1. (Think you have enough headaches for 5). Not sure if the rewrite makes this any easier, but being able to async render on the server would be a killer feature.

AlbertMarashi · 2024-04-17T12:30:29Z

I have this usecase where I am dynamically loading SVG icons by name from an API endpoint.

Unfortunately, it doesn't render in SSR

<script lang="ts">
import PlaceholderIcon from "./icons/PlaceholderIcon.svelte"

export let name: string

async function load_icon(name: string) {
    const res = await fetch(`/api/icon/${name}`)
    const text = await res.text()
    return text
}

$: icon_svg = load_icon(name)
</script>
{#await icon_svg}
    <PlaceholderIcon/>
{:then svg}
    {@html svg}
{/await}

Would be pretty sweet to have async components for this sort of use case (or like being able to top-level await in components)

Rich-Harris mentioned this issue Dec 10, 2017

Streaming SSR renderer #653

Closed

arxpoetica added the feature request label Jan 7, 2018

This was referenced May 28, 2019

SSR with async data scottbedard/sveltober#5

Open

Data fetching with SSR EmilTholin/svelte-routing#38

Closed

arggh mentioned this issue Nov 5, 2019

Woes with SSR and Promises #3853

Closed

jimafisk mentioned this issue May 12, 2020

Components are undefined in HTML plentico/plenti#20

Closed

mindrones added the feature: SSR label Jul 18, 2020

Conduitry mentioned this issue Sep 10, 2020

Dependency tag #5351

Closed

AlbertMarashi mentioned this issue Oct 20, 2020

Feature: List rendered components during SSR #5476

Closed

2 tasks

pngwn added temp-stale and removed feature: SSR labels Jun 27, 2021

dummdidumm removed the temp-stale label Jul 11, 2021

Conduitry mentioned this issue Aug 4, 2021

Some way to wait before send SSR results sveltejs/kit#2084

Closed

bfanger mentioned this issue Jan 14, 2022

Top-level await in script and / or nuxt-like server data fetching sveltejs/kit#3043

Closed

kryptus36 mentioned this issue Oct 18, 2022

Top-level await #5501

Open

kryops mentioned this issue Jan 25, 2023

Server rendering QR code kryops/pdfmake-html-renderer#2

Open

Rich-Harris added this to the 5.x milestone Apr 1, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Async/streaming SSR renderer #958

Async/streaming SSR renderer #958

Rich-Harris commented Nov 25, 2017

JulienPradet commented Jan 27, 2020

AlbertMarashi commented May 13, 2020

AlbertMarashi commented May 13, 2020 •

edited

Loading

AlbertMarashi commented May 13, 2020 •

edited

Loading

AlbertMarashi commented May 13, 2020 •

edited

Loading

maxcoredev commented Oct 3, 2020 •

edited

Loading

blairn commented Oct 3, 2020

AlbertMarashi commented Oct 3, 2020

maxcoredev commented Oct 3, 2020 •

edited

Loading

roblabla commented Jul 12, 2021

kaushalyap commented Sep 15, 2021

y0zong commented Jun 10, 2022

kryptus36 commented Jun 11, 2022

Evertt commented Jul 1, 2023

lucidNTR commented Nov 28, 2023

crisward commented Feb 10, 2024

AlbertMarashi commented Apr 17, 2024 •

edited

Loading

Async/streaming SSR renderer #958

Async/streaming SSR renderer #958

Comments

Rich-Harris commented Nov 25, 2017

JulienPradet commented Jan 27, 2020

AlbertMarashi commented May 13, 2020

AlbertMarashi commented May 13, 2020 • edited Loading

AlbertMarashi commented May 13, 2020 • edited Loading

AlbertMarashi commented May 13, 2020 • edited Loading

My ideal setup/flow would work something like this:

Alternatively

Right now

maxcoredev commented Oct 3, 2020 • edited Loading

Now we can write clear pragmatic code that will produce exact same result on both SSR and browser

blairn commented Oct 3, 2020

AlbertMarashi commented Oct 3, 2020

maxcoredev commented Oct 3, 2020 • edited Loading

roblabla commented Jul 12, 2021

kaushalyap commented Sep 15, 2021

y0zong commented Jun 10, 2022

kryptus36 commented Jun 11, 2022

Evertt commented Jul 1, 2023

lucidNTR commented Nov 28, 2023

crisward commented Feb 10, 2024

AlbertMarashi commented Apr 17, 2024 • edited Loading

AlbertMarashi commented May 13, 2020 •

edited

Loading

AlbertMarashi commented May 13, 2020 •

edited

Loading

AlbertMarashi commented May 13, 2020 •

edited

Loading

maxcoredev commented Oct 3, 2020 •

edited

Loading

maxcoredev commented Oct 3, 2020 •

edited

Loading

AlbertMarashi commented Apr 17, 2024 •

edited

Loading