Server fetched resources not sent to client when not used in initial render, then it stucks on client

[XiNiHa]

Describe the bug

If a server-fetched resource is not used in the client on the initial render, the server does not send the result of it to the client. And later, when the client tries to use the resource, the closest Suspense triggers but the resource gets stuck in the pending state, and the fetcher never gets called.

Your Example Website or App

https://github.com/XiNiHa/solidjs-streaming-resource-repro

Steps to Reproduce the Bug or Issue

1. Go to the index route.
2. (Optional) check that the initial response doesn't contain the resource fetch result, "foo".
3. Click the button.
4. The Suspense at the right of the button triggers and it never gets resolved.
5. Check the console to verify that the fetcher never got called in the client.

Expected behavior

I expect a number of behaviors that could be considered valid:

1. Always stream the resource result whether or not it is used during the initial render. (I expect this as the best when renderToStream is used, but not sure when renderToStringAsync is used)
2. Don't stream the resource. But let the client fetch the resource again when it's needed.
3. Throw an error that the resource value is not available while the stream is already closed.

Screenshots or Videos

No response

Platform

• OS: Both verified on macOS and Linux
• Browser: Firefox
• Version: 111.0

Additional context

No response

[lxsmnsyc]

This isn't an issue. createResource would run in the server however since you're reading the data function conditionally in this line:

https://github.com/XiNiHa/solidjs-streaming-resource-repro/blob/444fb56b272f0081a7ddaa8279518d61065c24b4/src/routes/index.tsx#L34-L37

wherein props.useResource is false initially, there's no way for the server to wait for this resource. Set useResource signal' initial value to true and you'll probably have no issues.

[XiNiHa]

I know that setting the value to true resolves the issue, but that's not the point. It's clearly an unexpected behavior that the resource gets stuck forever without any errors. If the team considers this a non-issue, I think at least the third expected behavior I suggested (throwing an error) should be implemented.

[lxsmnsyc]

It's tricky, since the server will only know the resource is awaited if the data function is called. There's really no reason to throw an error here since in some cases, a resource is likely to be deferred.

But if you're asking if this is the expected behavior, yes and this is also by design

[XiNiHa]

There's really no reason to throw an error here since in some cases, a resource is likely to be deferred.

The problem is that it's not even possible to defer the resource since the data will never be available because of the bug I've described above. (the client never tries to fetch the data) Sounds like you are expecting the second behavior I've suggested?

[ryansolid]

Yeah.. lets look at how we can at least do something when the stream closes if the resource isn't present and has been communicated.