Replies: 1 comment 2 replies
-
Maybe it was a bad idea. Let me change the signature. Found this comment too. It's better to not wrap ReadableStream on our end. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I see React has an
allReady
promise that can be used to wait for all content to render instead of sending the shell as early as possible.https://react.dev/reference/react-dom/server/renderToReadableStream#waiting-for-all-content-to-load-for-crawlers-and-static-generation
Maybe there can be a setting in the waku context that middleware can update to turn on awaiting the allReady promise from the response stream? The Waku streamFromPromise function makes it inaccessible. After
const stream = await promise;
, we need to putstream.allReady
somewhere that it can be accessed. I triedthis.allReady = stream.allReady
but that didn't seem to work to set a prop that was accessible at ctx.res.body.allReady. Maybe it requires extending ReadableStream.To reproduce the streaming behavior, take the default create-waku template, edit the layout to have a suspense boundary:
in pages/index.ts, change the render to 'dynamic' and add
await new Promise((resolve) => setTimeout(resolve, 10000));
in getData.Now if you run the dev server and open in your browser, you should see "Loading..." for about 10 seconds and then the normal content.
If you use curl (
curl -N http://localhost:3000
), you'll see it do the same thing.Now edit
node_modules/waku/dist/lib/utils/stream.js
and putawait stream.allReady;
in streamFromPromise after theconst stream = await promise;
line and restart the dev server. You will see that the server waits to send all of the html.What's really interesting is it actually replaces the suspense content in the html when we use
await stream.allReady
:without awaiting, the html has this:
Beta Was this translation helpful? Give feedback.
All reactions