Clarification on safely using stores in Sveltekit

[nikfp]

After much internet searching, I haven't found a clear answer to this so I thought I better go to the source.

There is a lot of confusion across the internet regarding how stores behave in Sveltekit, Mainly, there is ambiguity is to how you scope a store to one client and NOT share it across connections, users, etc. It's brought up in this discussion, and I feel it would be a huge benefit to users to clarify this in the docs. I can't state as to how though (yet) because I'm not 100% sure how it works myself.

Finding a clear answer has proven elusive, and the docs only really have this to say:

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.

In vanilla Svelte, stores are straightforward. However since SK introduces a server, and with module resolution the way it is, I can see how the module would resolve once in memory and then get reused as mentioned in the referenced discussion. So my question is two fold:

• What is the correct way to use stores in SK, and how do they differ from vanilla Svelte? is $page.data all we get safely?
• How could this be better documented so others have a clear direction on how to do this securely and efficiently?

Also worth mentioning that I love Svelte and one of the big reasons why is the docs. I was able to learn vanilla svelte entirely from the docs and REPL and picked up Sveltekit through the docs, demo app and mucking around, and didn't need or want a tutorial. Anything I can do to add clarity or help make the docs better for others, I'm on board with.

[DrDanRyan]

I have figured out a little info that might help people. My use case was that I have data in my main layout that I want to be able to set from various pages (think maybe badges in the header or something like that). For example let's assume we have some variable points that we want to reactively update in the layout component when things change on various pages.

In +layout.svelte:

import { setContext } from "svelte";
import { writable } from "svelte/store";
export let data; // initial points value comes from the layout load function

let points = writable(data.points); // create a writable store
setContext("points", points);   // the first argument is the name of the context, the second is its value (a writable store)

Then, somewhere in the layout body you subscribe to points by referencing $points in your html.

Then say we are in some +page.svelte file and did a json fetch to update the user's points value and we want to update the new points value in the layout. In +page.svelte do

import { getContext } from "svelte";
let points = getContext("points");  // get the writable store by using its name

async function addPoints(amount) {
    const newPoints = await fetch( ); // assume this fetch updates the user's points and returns the new total
    points.set(newPoints);  // this line will cause a reactive update in the layout
}

I hope this helps. The basic idea is that setContext can make writable stores available to all child components (including slotted components) and then the child components/pages can use getContext to effectively "import" the writable store and set/update its values.

[KaviiSuri]

This makes sense, but what if you have a class/module/function that's outside the svelte component tree?

[AlbertMarashi]

I have created a proposal for solving this issue, as it's one of the most important discussions brought up by developers
#9878

[MPLLC]

After much internet searching, I haven't found a clear answer to this so I thought I better go to the source.

There is a lot of confusion across the internet regarding how stores behave in Sveltekit, Mainly, there is ambiguity is to how you scope a store to one client and NOT share it across connections, users, etc. It's brought up in this discussion, and I feel it would be a huge benefit to users to clarify this in the docs. I can't state as to how though (yet) because I'm not 100% sure how it works myself.

Finding a clear answer has proven elusive, and the docs only really have this to say:

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.

In vanilla Svelte, stores are straightforward. However since SK introduces a server, and with module resolution the way it is, I can see how the module would resolve once in memory and then get reused as mentioned in the referenced discussion. So my question is two fold:

* What is the _correct_ way to use stores in SK, and how do they differ from vanilla Svelte? is `$page.data` all we get safely?

* How could this be better documented so others have a clear direction on how to do this securely and efficiently?

Also worth mentioning that I love Svelte and one of the big reasons why is the docs. I was able to learn vanilla svelte entirely from the docs and REPL and picked up Sveltekit through the docs, demo app and mucking around, and didn't need or want a tutorial. Anything I can do to add clarity or help make the docs better for others, I'm on board with.

I agree 100% with the docs needing an overhaul. Not just to keep up with the currently rapid changes the product is going through, but because they read like they're written by and for people already super familiar with other JS/node frameworks, if not SK itself, instead of being aimed towards newbies.

I'm not saying this out of malice but out of support/concern. I'm no stranger to reading online documentation, but when I read sections like what you posted here, or what I started a conversation about re: shared state I get a bit frustrated because the text assumes (unfairly, IMO) underlying knowledge that someone reading the docs wouldn't necessarily have.

I get that docs will lag a bit behind as a project undergoes changes. Hell, as I write this Typescript itself is currently at version 4.8.2 yet the docs are still for 4.7. But the SK docs need a lot of love regardless, especially when it comes to illustrative code examples, common use cases, and best practices.

Again, none of this is said/meant with any malice.

[j4w8n]

I agree. The LOADING DATA > Shared state section of the docs isn't clear to me either.

per-request vs per-user
shared variable vs global variable (vs ?normal? variable)

I understand per-user, but not necessarily per-request. I guess it means server requests, which would hit handle() where you typically set event.locals and eventually pull that data into a load(). So maybe a use-case for per-request would be if you're passing the source IP address of a request to the server-side, make sure it's sent via event.locals. But I don't get how that relates to must not be stored in shared variables outside your load functions. I'm sure it does relate, my brain just needs an example to understand since I'm not sure what a shared variable is.

After my own research into alternative ways to replace the deprecated SvelteKit $session store, it seems like you should never use a "plain, non-scoped" store to hold user data. And that the SvelteKit $session store itself was using context under the hood to make sure it was scoped.

Regarding context, I put together the below code based on various discussions and the Svelte tutorial. But I quickly abandoned this for $page.data and invalidate(). depends() can come into play here too. But, to riff off your post, I don't fully understand how to properly use invalidate and depends.

<script>
  import { keys } from '$lib/keys'
  import { getContext, setContext } from 'svelte'
  import { writable } from 'svelte/store'

  /* create scoped $session store */
  setContext(keys.session, { session: writable() })

  /* get-use scoped $session store */
  const { session } = getContext(keys.session)
  $session = $page.data.session

  /*
  ** I like the idea of using $lib/keys if you have more than one "scoped store".
  ** Otherwise, you can probably use `setContext(Symbol(), { session: writable() })`
  **
  ** https://svelte.dev/tutorial/context-api talks about Symbol() in the 'Context keys' section.
  ** Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
  ** 
  ** export const keys = {
  **  session: Symbol(),
  **  whatever: Symbol(),
  **  whatelse: Symbol() 
  ** }
  **
  */
</script>

[cdcarson]

Agree. It's unclear whether this section is talking about the general "Node vs PHP" scopes thing (i.e. PHP automatically creates a "global" scope for each request, whereas all requests in Node share a global scope,) or that plus something specific to SvelteKit.

What might be really useful is a "Don't do this" counterexample to show the way(s) in which global state could be accidentally polluted.

[dummdidumm]

Agree with all of you, the docs need to get better (not just at this but in general). Some of this is probably out of scope for the docs, but with learn.svelte.dev we likely have a home for recipes etc which can go into more detail about stuff like this.

[AlbertMarashi]

@nikfp and everyone else facing these similar types of issues.
I have created a proposal to solve this issue

• allows file-based stores to be used, ergonomically
• safe from cross-request contamination
• simplifies a lot of code, and makes typing more accessible
• allows typescript files to import stores without side effects

#9878

[alecStewart1]

I agree the docs could be better, though some things may just be because I'm not the brightest. What I could gather and the simplest way I can understand it:

• +page.(js/ts) and +page.server.(js/ts) are for ALL clients, so like blog posts or if you're fetching some media that all users can see. So you could use stores here, but those stores are "seen" by every client. So a user permissions and information should not fetched from here nor stored in $page.data.
• stores, by themselves, are for data for individual clients, so getting and checking an individual client's permissions for other data on a page(s) and getting data for an individual client.

This is my understanding.

[nikfp]

See, I understood this the opposite way. The page data store from my understanding is where you put things specific to one client. So yes we need some clarity here Thanks, Nik P

…

On Wed, Jun 21, 2023, 3:40 PM Alec Stewart ***@***.***> wrote: I agree the docs could be better, though some things may just be because I'm not the brightest. What I could gather and the simplest way I can understand it: - +page.(js/ts) and +page.server.(js/ts) are for ALL clients, so like blog posts or if you're fetching some media that all users can see. So you *could* use stores here, but those stores are "seen" by every client. So a user permissions and information should *not* fetched from here nor stored in $page.data. - stores, by themselves, are for data for individual clients, so getting and checking an individual client's permissions for other data on a page(s) and getting data for an individual client. This is my understanding. — Reply to this email directly, view it on GitHub <#6098 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALGFKRZ4UFBNVT2P2TKUY7LXMNS45ANCNFSM57BYKDWA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wbhob]

Now that Runes are here, I wonder how this problem will evolve. Will each app instance be able to use shared runes without having to use contexts, or will they also be unscoped by default and we have to use context for every minute bit of state. I really hope we see a solution to this soon, because the notion that web apps are going to fetch ALL their data before loading an iota of UI is nonsense (streaming still does not work in Safari), and writing an entire library of boilerplate doesn't exactly feel like the Svelte way.