Caveats with passing the load-fetch into script for SSR?

[MoritzKronberger]

A bit of background:

I am using SvelteKit with tRPC and Svelte Query and I am trying to get credentialized server-side requests to work. Svelte Query's useQuery must strictly be used on component initialization so I can't use the usual approach of running the queries inside the fetch function.
The workaround I found, has been to instantiate the tRPC client using the load function's fetch in my root-+layout.ts and accessing the client from the PageData prop in my pages.

My question:

Since the load function's fetch is not available inside the page's/layout's script by default (please correct me if this is wrong), I was wondering if there are any potential issues/concerns with passing fetch into the page script?

[teemingc]

Hi Moritz,

Sorry, I think I am misunderstanding something. Is there an error if you use a normal fetch in the script tags? Are you able to manually pass the credentials through the authorization header?

[MoritzKronberger]

Thanks for your input! Sorry, I didn't see your edit before sending my reply.
Yes, the regular fetch only becomes problematic when tring to access procedures requiring authentication, since no authentication headers are copied over. Because I'm not using fetch directly, but rather through the tRPC client I don't see a straightforward way to manually pass authentication headers.

Using load-fetch inside the script tag during SSR conveniently solves this problem for me, however I'd like to make sure that abusing load-fetch this way won't cause any problems down the line.

[teemingc]

The only thing that comes to my mind is if passing the load function as data could be expensive? (Adds more bytes to the initial network request?)

[MoritzKronberger]

That seems reasonable, although I haven't experienced any issues with the request size in my relatively small app.
After a bit more research, I opted to ditch Svelte Query altogether, since using SvelteKit's load function on its own is enough for most of my use cases anyway and keeping all my procedure calls inside load completely avoids any potential problems.