Rendering asynchronous component throws an error

[aminnairi]

Describe the bug
When rendering an asynchronous component using import { lazy } from "preact/compat", the rendering fails and throws an error.

The error is a promise, and when resolved, it resolves to the component that was lazy, causing weird glitches on the server.

To Reproduce
Steps to reproduce the behavior:
Follow instructions for the reproduction repository here.

Expected behavior
import { render } from "preact-render-to-string" should return a promise that resolves to the whole rendered string.

Screenshots

Browser (please complete the following information):

• OS: [e.g. Windows 11]: Arch
• Browser [e.g. Chrome 108]: Chrome 108

Node (please complete the following information):

• Platform: [e.g. Node 18]: Node 19.3.0
• Package Manager [e.g. NPM 8.2.13]: NPM 8.19.2
• Package Version [e.g. 0.2.1]: 5.2.6

Additional context
It would be even better to have a different implementation in order to prevent implementing breaking changes with a function that would indeed account for lazy components ala ReactDOMServer.

import { renderToPromise, renderToStream } from "preact-render-to-string"

console.log(await renderToPromise(<Main />))

renderToStream(<Main />).pipe(process.stdout)

[rschristian]

The good news is that this is super simple to implement in user land.

Here's a (very slightly) modified excerpt from preact-iso/prerender inserted into your example showing how you could implement this:

import { renderToString } from "preact-render-to-string"
import { Main } from "./main"

const main = async () => {
    let tries = 0;
    const maxDepth = 10;
    const render = () => {
        if (++tries > maxDepth) return;
        try {
            return renderToString(<Main />);
        } catch (e) {
            if (e && e.then) return e.then(render);
            throw e;
        }
    };

    const rendered = await render();
    console.log(rendered)
}

[JoviDeCroock]

Alternatively you can use preact-ssr-prepass to do one pass that optimises parallel promises/... so first prepass and then renderToString

[aminnairi]

The good news is that this is super simple to implement in user land.

Here's a (very slightly) modified excerpt from preact-iso/prerender inserted into your example showing how you could implement this:

import { renderToString } from "preact-render-to-string"
import { Main } from "./main"

const main = async () => {
    let tries = 0;
    const maxDepth = 10;
    const render = () => {
        if (++tries > maxDepth) return;
        try {
            return renderToString(<Main />);
        } catch (e) {
            if (e && e.then) return e.then(render);
            throw e;
        }
    };

    const rendered = await render();
    console.log(rendered)
}

Thank you for your reply, I'll try to create a reproduction of this fix in a separate branch to confirm that this is working and will push the updates to the repository I linked for the issue for people seeking answers like me.

Any reason why an error has been thrown, when this is not really an error but a promise? I'm really curious about the implementation details of this render function but I somewhat doubt I'll be able to understand any of this internal working.

Is renderToString documented somewhere? I feel like I've missed something here.

[aminnairi]

Alternatively you can use preact-ssr-prepass to do one pass that optimises parallel promises/... so first prepass and then renderToString

Thank you for your reply.

Makes sense since when testing with a fully-fleged routing application I get this promise-error thingy the first time I try to render the page, and then it renders correctly on subsequent calls to the server.

But it is making Lighthouse crazy if you try to first-request your server with it.

I'll give preact-ssr-prepass a try if it means less implementation from the userland (what would be the ideal solution for me and maybe other non-power users).

[JoviDeCroock]

The way lazy and other Suspense mechanics work is basically throwing a Promise upwards at the point of async, this because VDOM is inherently boundary-based which means that if something within a boundary errors or can't render we need to throw so we can go up to the closest boundary to or react to the error or await the promise.

[aminnairi]

The way lazy and other Suspense mechanics work is basically throwing a Promise upwards at the point of async, this because VDOM is inherently boundary-based which means that if something within a boundary errors or can't render we need to throw so we can go up to the closest boundary to or react to the error or await the promise.

Makes much sense now I see why, thank you very much for your insight!

Any reason why this is not done by default if this is the intended behavior behind Suspense & lazy? Or maybe is there some key differences in the implementation between react & preact for those component inside preact/compat?

[aminnairi]

Alternatively you can use preact-ssr-prepass to do one pass that optimises parallel promises/... so first prepass and then renderToString

I can confirm that the preact-ssr-prepass package is working as intended, even with my own router when rendering on the server a VNode that has is lazy.

I feel like this can be (and should be) added in the documentation for people wanting to render asynchronous component (even with a custom implementation bound to this repository to not be dependant of any external libraries).

[JoviDeCroock]

We have discussed supporting this internally quite a bit but on the team we aren't a 100% sure whether this is the best abstraction and we're on the lookout on what to support. Hence our current recommendation being preact-ssr-prepass.

Historically Pre React 18, the error you are describing happened in React as well, where react-ssr-prepass was introduced to counter-act this, after React 18 it just renders the Suspense fallback which imho isn't really ideal either 😅

My assumption is that streaming rendering will be the answer here as that could elegantly hook into these boundaries.

EDIT: documenting is a good shout, thank you!

[rschristian]

Is renderToString documented somewhere? I feel like I've missed something here.

It's the exact same thing as render, there's no difference. Just switched up the import name to avoid the conflict is all.