SSR blank page
Hi everyone, I'm having a little issue in solid start, when I'm using createAsync with the following query, the initial page response is blank, the page has two createAsync, one for the getSession an the other for this request to retrieve the guilds from discord, when there's only the getSession query the initial load of the page has elements rendered from the server and works as expected, I'd appreciate any help on this



34 Replies
The suspense was a try to wait for the guilds in the client, but initially I didn't have it, but either using suspense or not, gives me a blank page from SSR
It's because guilds is read in the memo which causes any above suspense to trigger
If I commet the memo and remove the suspense and read the plain value of guilds the issue persists
This line:
The
query
wrapper is only intended for client side code which includes SSR but not "use server"
or pure server code.
So what you need to do is factor out getMaybeSession
's core into a pure server function and reuse that core function inside getMaybeSession
and getSession
via an import
.It's weird because as I mentioned if I remove all the getGuild logic an leave only the getSession I indeed receive a server rendered page in the first load
The blank page from SSR only happens if I cal the getGuild function
Nevertheless
query
wrappers are meant for client code, not server code.If I do what you mentioned, wouldn't it mean that the session will be fetched twice if I call the "getMaybeSession" and getSession" in the same page, instead of dedup the request?
Also if you want SSR rather than streaming use
createAsync(…, { deferStream: true })
.
wouldn't it mean that the session will be fetched twice if I call the "getMaybeSession" and getSession" in the same page, instead of dedup the request?What you're doing wouldn't in any way prevent that. Each
query
is it's own thing and each "use server"
is a separate RPC request (unless query
results are bundled via single-flight as a result of an action
).
and you're doing it in getGuilds
again:
So again factor it out to a pure server function and reuse the import in both getSession
and getGuilds
.I made the following changes, and I still receive a blank page from SSR




I change the session queries because error on client, trying to acces environment variable sin client, but the issue persists

I think the issue is using fetch

This is a different example that causes the same issue
Is there a suspense boundary above
Page
?The only Suspense is the default in app.tsx
That should be enough for SSR.
This is the response from the server with the current code

The
fetch
as such shouldn't be a problem but the fact it's behaving differently makes me wonder if it has to do with the page streaming.
From that perspective I wonder whether adding { deferStream: true }
to the createAsync
s would change anything;I try it and yes, it holds the response until it fetches, whys is that?
The last time I checked in a toy example, it didn't matter how much time the query took to return, the page didn't load until it was resolved
Without
{ deferStream: true }
the page doesn't wait until it has all the data to render the full page and just sends what it can render immediately.
Once the promises resolve on the server, seroval (de)serializes the data and sends it to the client which renders the rest.Weird, the last time I checked it worked different
The doc examples should mention that somewhere
Your test only provided one guild and I guess a fetch could possibly provide many guilds. Is it possible that one of the other library's interacting with the guild data is trashing the SSR?
So perhaps the fetch would start to work if you simply displayed the number of records returned while stripping all the other functionality from
Page
.
I assume in the fetch
case you threw in a console.log
(to appear on the server side) before the return to ensure that the response data being returned looked sane.Unrelated but aside" What made you choose
Index
instead of For
in Page
?
Index
tends to be used when the items are just primitive values because the “DOM-per-item” is then just left in place while the values are just “Re-slotted” when required.
For
tends to be used with “object items” (keyed) as their “DOM-per-item” is associated with the object's identity and that “DOM-per-item” moves with the “object item” within the list.
https://docs.solidjs.com/concepts/control-flow/list-rendering#index-vs-forList rendering - SolidDocs
Documentation for SolidJS, the signals-powered UI framework
Oh, I misunderstood the use, I tought Index was for index that doesn't reorder usually, and For for like reorderable lists or lists that tends to change frequently
As far as I tested, the only thing that affects the loading page was the fetch, removing v alibot for example didn't change the result, only when I was removing the fetch
And I didn't understand the part of showing only the number of record, what do you mean, making the request but instead of returning the objects just the length of the array?
Yup, when I console.log in the server function the data returned by the fetch looks good, and returns pretty fast, idk why in the Page it takes more time
And I didn't understand the part of showing only the number of record,The intent was to strip down
Page
to just SolidStart functionality just to ensure that processing of the actual guild data returned by the fetch
wasn't contributing to the defect.
the data returned by the fetch looks good,One experiment could be to perform the fetch but return the simpler test data. While I expect this would still fail if it actually works it would point towards the data (processing) being the culprit. If it fails another experiment would be to return the test data via a delayed promise in order to determine whether there is some sort of weird timing issue (my guess is that it will still work). Ultimately you can only go only so far diagnosing this by code review. The actual problem could still be upstream of the
fetch
, the fetch
just being the needle that breaks the camel's back. Countless times the actual root causes to issues in the support channel aren't actually found within the code that was presented during the support discussion.Idk if it could be affecting, but in the project I'm using bun as a package manager and for running the commands I se
bun dev
as fas as I know bun uses nodefor running vite
I didn't check but with the refactor for session I made yesterday, know it also returns a blank page when using only the session query
and previous to the change it was pre rendering whe using only that query
I will make a build to check if it works properly in prod, and if the error is only in dev
It al;so happens in prod, but it's kinda weird, because, it feels like I'm getting a server renderd page in time, but the response is a blank page
The only thing I can imagine is messing up with the SSR is the paraglidemiddleware
@peerreynders Well I think it would be much easier if I provide all the code, so here's my repo with all the stuff I trying to do
https://github.com/SkyLissh/skylet-discord-dashboard/tree/feature/authI made a new project and created a simple example with a fetch, I just added the example query, and the result is the same, a blank page

Runs without issue:
node: v22.14.0
pnpm: 10.7.1
Ubuntu 22.04.5 LTS
That’s probably a bun thing.
There’s an issue :
https://github.com/oven-sh/bun/issues/11381
may be unrelated.
And I found this:
"Vinxi project such as solid-start doesn't work with Deno 2.0
Here is a repo: https://github.com/Ciantic/deno-solid-test
This most likely because Vinxi runs node.exe behind the scenes instead of deno.exe.
It's notable that bun also has same error, but it can be fixed by using a flag --bun that fakes bun.exe as node.exe."
GitHub
Bun does not implement
fetch()
API correctly · Issue #11381 · o...What version of Bun is running? 1.1.8 What platform is your computer? Linux 5.15.146.1-microsoft-standard-WSL2 x86_64 x86_64 What steps can reproduce the bug? Bun malforms request when using overlo...
bad code delete it all
But in the network tab you receive a pre rendered page?
I made the same example with node: 22.13.1 and pnpm: 10.8.0
I wouldn't expect to given that
{ deferStream: true }
wasn't used. i.e. it would only be partially rendered.So by default solidjs use something like partial pre rendering in nextjs, instead of waiting for the data called in the queries?
I think I didn't understand at first because every other framework by the default waits the page, and only do partially pre-rendering when you specify to do so
Result from “View Page Source”.
instead of waiting for the data called in the queries?SolidStart's default SSR behaviour is to render synchronously what it can and stream the rest in via seroval via a streaming response to the initial request (which I did mention earlier, here). “View Page Source” after:
good, you deleted, change your access token