SvelteKit and shared state - can someone give a concrete example of when to use event.locals vs. $page.data?

[MPLLC]

I come from a PHP/Symfony background, so using a non-MVC TS framework for both back end and front end development is completely out of my wheelhouse. Apologies in advance if this question is answered elsewhere. What follows is a question I asked on Stack Overflow (here) which has yet to receive an answer:

The official SvelteKit docs have this little blurb regarding shared state:

In many server environments, a single instance of your app will serve multiple users. For that reason, per-request state must not be stored in shared variables outside your load functions, but should instead be stored in event.locals. Similarly, per-user state must not be stored in global variables, but should instead make use of $page.data (which contains the combined data of all load functions) or use Svelte's context feature to create scoped state.

From what I've seen of the docs, it's one of two places where event.locals is even mentioned, with the other brief mention being simply that its interface exists in src/app.d.ts.

So, my question is: what would constitute data I would want to store globally versus locally? Is there a common use case where event.locals is the way to go? It seems like there's a missing, yet important, distinction/rule-of-thumb that should be explicitly illustrated in the docs.

[cdcarson]

It's been a while since I did PHP directly, but the main difference with Node is that Node has one global scope. So you can't do something like $_SESSION in the global scope, since that would be shared amongst all requests (i.e. all users.) The way around this in Node is to scope to the Request. The server listens for a Request, passes it to SvelteKit, and Kit passes a wrapped version of the Request to your handler. This RequestEvent has the request itself, plus several other useful properties, like locals.

what would constitute data I would want to store globally versus locally?

Global on the server: I'd keep the global stuff to a minimum. I have a database connection pool and a Redis client. The environment is also global.

"Locally" on the server means "scoped to the request in event.locals." I'd also keep this to a minimum, preferring to do most of the work within the scope of the handler function rather than spread across middleware. (Middleware is why event.locals exists in the first place.) I just use event.locals to store the signed in user. Again, this doesn't happen automatically. You have to instantiate that user for each request from, say, a cookie.

On the client SvelteKit exposes a set of "readable stores" that are shared across client-side router navigations. page is one of those. I haven't messed with page.data yet (there have been many recent changes) but it looks like it would contain the current page's data -- what's been passed to the page component by export let data. (Don't take my word for it.)

[nikfp]

@cdcarson is correct, and I can add to you need to be aware of your deployment target as well. If you plan to run Sveltekit as a long running process, be very careful about keeping things scoped to the current request. (aggressively so!) Since Node resolves each dependency once and then serves it from a cache, each dependent is using the same object in memory to work against, i.e. shared state is easy to do - and easy to share by accident if you aren't thinking about it. The good news is that SK has mechanisms to get around this using prescribed methodology in the docs, so that should be your preferred approach.

Even if you plan to run SK in an edge function or serverless environment, this can still be an issue and worth considering, though less so. Edge tech will keep the endpoint "hot" for a short time period and it's conceivable that a request could come in from a different user to a hot function and state could be shared. This would of course be less of an issue than in a long running situation, but you get the idea.

When in doubt, the best practice is to build up a context for each request through the handle hook and *.server.js files and pass the info you need through $page.data to the front end. This will minimize the possibility of accidentally sharing state that you don't want to share and keep your server functionality stateless. (and scalable if needed)

[MPLLC]

Ah, okay, it's starting to get a little clearer. And, yeah, I was wondering how one would, say, keep a user logged as they moved from page to page in a SK app. I did read that the previous session functionality was removed, but wasn't sure exactly how to implement a PHP-esque session with what currently exists.

Assuming the data handling part of SK stays more or less the same, I'd really like to see a few common use cases illustrated in the docs. I can't be the only one that comes from a background outside of node that's been scratching their head, and it's a bit of an ask to expect people to dive through Github discussions and issues.

[nikfp]

I expect that once SK hits v1.0 we'll start to see a ton of example repos and probably a central location to find them. Nextjs does this now, but they are also on v12 with much broader adoption, so common configs and patterns have had the time and room to develop. I agree it's an ask right now to get into docs and Github for clarity, but it will get better. (And the docs should always be clear anyway. SK needs to work on this, vanilla svelte at svelte.dev has this right)