# Idea For discussion of the problem, see [[data leakage with SvelteKit global variables and stores]]. Best practices to mitigate the problem: Avoid using global stores in server side, endpoints, actions, or load functions. Avoid mutating shared state on the server. Ensure that your server-side logic doesn't inadvertently depend on or modify global state based on the received store values. Use `event.locals` to pass custom data. It takes care of this and is one simple way to share data on the server side that is unique to the client session. event.locals are what their name says, they are states localized to the lifespan of individual server-request events. They are independent, i.e. they are not persisted across requests (but they are persisted across handlers running in the context of the same request, i.e. handlers sequenced by your handle hook. Always create a store inside a component and use contexts. See [[svelte - context API]]. - https://www.youtube.com/watch?v=MBSYHW50xb8&t=1832s Avoid modifying store values in the server. If the server is only reading the store values sent in the request and not modifying the global store, you avoid the risk of one user's actions affecting another user's state. Each request is treated independently, carrying its own set of store values. This maintains proper isolation between different users and sessions. The server should only receive the store data with each request, processe it without modifying any global state, and return a result to the client. Use global stores with context. The state from `setContext` isn't able to be referenced globally, since it's initialized inside of (2) closures in this example - the `<script/>` tags, as well as the `setUserState()` function. You can't reference something within those functions from outside of them, unlike a global object or global writable being exported from some module. Yes but the context in and of itself isn't what's helping here, it's the fact that we have the creation of that store being done inside of a function, and the state itself isn't being exported from a global module. A good rule of thumb is to never put the keyword `export` in front of some state that you wouldn't want potentially persisted between requests. - https://www.youtube.com/watch?v=EyDV5XLfagg Server-side functions should be [[pure functions|pure]]—no side-effects. Use server-side sessions to manage user-specific data. Do not store sensitive information in stores. Use stores primarily for UI state and not for data that should be user-specific. If you only need to load some data when a page loads, look at Page Data. $page.data is a per-client store built into SvelteKit that you populate with a load function and access via a single line (export let data) in your component. It's really cool and if it works for your structure, do it! Otherwise, use the Context. # References - [In sveltekit, is it okay to pass stores as parameters to functions?](https://www.perplexity.ai/search/in-sveltekit-is-it-okay-to-pas-koyaQriUTuymhlz6RRg1iQ) - [State management • Docs • SvelteKit](https://kit.svelte.dev/docs/state-management) - [Safe SvelteKit Stores for SSR - DEV Community](https://dev.to/brendanmatkin/safe-sveltekit-stores-for-ssr-5a0h#stores-with-context) - [Using The Svelte Context API With Stores](https://joyofcode.xyz/svelte-context-with-stores)