Is SSR a possibility?

[ermincelikovic]

Hi folks,

I've been using the library for the last couple of hours and it's pretty straightforward, love it.

I was wondering if there would be a technical possibility to do server-side rendering of Authenticated/Unauthenticated components. Currently, Unauthenticated component is always briefly flashed (until js is executed), before the Authenticated content is loaded.

Cheers

[JeremyVoisin]

Hi @ermincelikovic,

Thank you for your suggestion, I started to work on an implementation for SSR to be an option when working with Authenticated or Unauthenticated.
The challenge here is to be able to read the session from a server while avoiding to use a server-side-store as server-side-stores are shared between users in SvelteKit.
An option would be to use the cookie storage option for the session, but it could bring undesired limits to using auth components and any other session storage option wouldn't benefit from such an implementation.
As I'm not sure to have the best solution for this really quickly, I added a "loading" slot to every component and I specially splitted Unauthenticated's slot in default and loading slots so the loading slot shows up when the store is not loaded yet, it should avoid the content to flash before js is executed 🙂

Cheers!

[ermincelikovic]

Hi @JeremyVoisin,

I'm relatively new to both Supabase and Sveltekit - so pardon my potentially basic questions.

There seems to be an SSR package/example for a session in the Supabase Auth Helpers repo:
https://github.com/supabase/auth-helpers/tree/main/packages/sveltekit

Or that's what you were referring to?

[JeremyVoisin]

Hi @ermincelikovic,

No worries, there is no bad question :)

Yes this is what I'm referring to, the Supabase Auth Helpers is really cool but is kind of a limiter. As we can see in most browsers now, there is a strict control of what cookies can do, and some are really more extreme and block all types of cookies.
We really would prefer an option which isn't dropping any capabilities of Supabase, and this is where I'm back to the challenge I described earlier.

[ermincelikovic]

Okay, I got what you mean. Very considerate of you! :)

Cookies for holding the ID to the user session are de facto standard - no?
I'm aware that it's getting more and more common that the third-party cookies are automatically blocked, but not the functional cookies from the web app itself.

EDIT:

If you want to give an option to the dev - it could be something along these lines:
<SupabaseApp {supabase} ssr={true}>

Or even using the default Sveltekit way of checking the export let ssr = true;.

[JeremyVoisin]

My usual users might be a bit different because I see more and more users blocking functional cookies as well! Happy too see it's not so common by the way 😄
Adding such a parameter could be an option indeed, I will give a try to different solutions and keep the best of it all!
Thank you again for your suggestion 🙂