Proposal for Svelte 5: Universal Reactivity & Safe SSR Global State?

[AlbertMarashi]

Important

I have managed to implement most of this proposal in user-land: Check out the npm package i've created to help solve this problem https://github.com/AlbertMarashi/safe-ssr

---

Context

I want to get some open-minded perspective from maintainers and community members to provide constructive feedback about the pros/cons/oversights and whether the idea is worth pursuing

The unsafe behavior of global variables during SSR (particularly global stores) has been one of the most persistently complained about issues with SvelteKit (sveltejs/kit#4339).

The way stores are currently implemented result in state being leaked across requests which presents a security risk especially for users that are unaware of this difference of behavior in client-side vs server-side apps.

Solution

Using AsyncLocalStorage (node:async_hooks) to we can implement cross-request isolation for stores, which is supported by every major server runtime.

• Docs: https://nodejs.org/api/async_context.html
• Clarification: This is only a server-side feature, and is not necessary on the browser side of things as the client is naturally isolated from other clients - web support for AsyncLocalStorage is not required
• Support: Appears to be supported by all major server runtimes
  • Cloudflare as node:async_hooks
  • Node as node:async_hooks
  • Bun as node:async_hooks
  • Vercel as node:async_hooks
  • Deno as node:async_hooks

Rough Proposal / Idea

My idea is that we might be able to use this feature to have Svelte 5 runes (eg: $state ) work in any javascript modules, including in +page.ts, +layout.ts, [Component].svelte, or any javascript/typescript files such that the data within is guaranteed to be uniquely isolated between requests.

Example usage

In practice, I don't expect anything much to change in behavior, except massive improvements in developer ergonomics as it would bridge the gap between client-side and server-side behavior, and make everything a bit more universal.

$lib/foo.ts

import { $state } from "svelte"

export const reactive_state = $state({ counter: 0 })

+page.ts

import { reactive_state } from "$lib/foo"

export async function load() {
  // we can mutate state even before component initialization!
  reactive_state.counter += 1
}

+page.svelte

<script lang="ts">
import { reactive_state } from "$lib/foo"
</script>
<!-- guaranteed to be 1, never more across SSR requests -->
{ reactive_state.counter }

Rough internal mechanism

svelte/internal/state.ts

// this code is shared between client & server
import { browser } from "$app/environment"

export const request_store = {
  getStore(): Symbol | undefined { throw new Error("AsyncLocalStorage not initialized") }
}

export function $state<T>(initial: T) {
  if (browser) {
    /* handle as normal */
  } else {
    // we are in server, so handle differently
    return ssr_proxy(initial)
  }
}


/* very incomplete & rough example to explain the usage */
function ssr_proxy<T>(initial: T) {
    const request_values: WeakMap<Symbol, T> = new WeakMap()

    return new Proxy({}, {
        get(prop) {
            let request_symbol = request_store.getStore();
            let value = request_values.get(request_symbol);
            if(!value) {
                // structured clone to prevent value from being mutated between requests
                value = structuredClone(initial)
                request_values.set(request_symbol, value)
            }
           
            return value[prop]
        }
    })
}

hooks.server.ts example to explain the point (although this would be moved into some other internal server-side only module)

// this code is only run on server-side
import { AsyncLocalStorage } from "node:async_hooks"
import { request_store } from "svelte/internal/state.ts"

const async_local_storage = new AsyncLocalStorage<Symbol>()
// replace the internal store with our async local storage
request_store.getStore = async_local_storage.getStore

export async function handle({event, resolve}) {
  // creates a new async local storage context
  // each request is given a unique symbol
  // any code executed inside `resolve` will have access to this unique request symbol
  return await async_local_storage.run(Symbol(), () => resolve(event))
}

Benefits

• Ability to use declare and use globally accessible stores in normal JS/TS files
• Universal behavior across client & server
• No more Cannot access 'x' before initialization
• Request-level isolation
• No security worries with data leakage between requests

Potential caveats & Open Questions

• This $state (when used in normal ts/js files) should only support proxy-able types (primitive types like strings and numbers can't be proxied) Pretty sure this is already a limitation with .svelte.ts files anyways
• only structured-cloneable type would be supported, however we could implement a feature to allow cloning of types other than this:
• Would [name].svelte.(ts|js) files be deprecated?
• How does this interplay in relation to $derived and other runes?
• More?

Allowing classes & other non-structured-clonable types to be cloned

1. Define a unique exported symbol in svelte, eg:

export const CLONEABLE_SYMBOL = Symbol()

import { CLONABLE_SYMBOL } from "svelte"

class MyClass {
   [CLONABLE_SYMBOL]() { /* manual implementation of clone behavior */ }
}

Related

• Sharing a global variable across multiple requests is unsafe in SSR kit#4339
• feat: implement prototype of safe server stores kit#12215

[AlbertMarashi]

Currently usable sample implementation

I'll probably be turning this into some sort of npm package that you can easily integrate into your projects.

• Caveat: the SSR-safe value must be wrapped in a getter
• Caveat: Need some kind of way to serialise this state across the server to the client, so both have the same state

$lib/request.ts

export const request_store = {
    getStore(): symbol | undefined {
        throw new Error("AsyncLocalStorage not initialized")
    }
}

$lib/app_state.svelte.ts

import { browser } from "$app/environment"
import { request_store } from "$lib/request"

export const app_state = $state(ssr_proxy({
    counter: 0,
}))


function ssr_proxy<T extends object>(initial: T) {
    if (browser) return { inner: initial }

    const map = new WeakMap<symbol, T>()

    return {
        get inner() {
            const req_symbol = request_store.getStore()
            if (!req_symbol) throw new Error("Request symbol not initialized")
            let value = map.get(req_symbol)
            if (!value) {
                value = structuredClone(initial)
                map.set(req_symbol, value)
            }
            return value
        }
    }
}

hooks.server.ts

import { AsyncLocalStorage } from "node:async_hooks"
import { request_store } from "$lib/request"
import { app_state } from "$lib/app_state.svelte"

// app_state.inner -> Error: AsyncLocalStorage not initialized

const local_storage = new AsyncLocalStorage<symbol>()
request_store.getStore = () => local_storage.getStore()

export async function handle({
    event,
    resolve,
}){
    // app_state.inner -> Error: Request store not initialized
    return local_storage.run(Symbol(), async () => {
       // should always be 0 at the start of a new request
       console.log(app_state.inner.counter)
       app_state.inner.counter += 1 // works, unique per request
    })
}

+page.svelte

<script lang="ts">
import { app_state } from "$lib/app_state.svelte"
</script>
<!-- will be 1 on load, and then switch to 0 on client-side hydration -->
{ app_state.inner.counter } 

[saturnonearth]

This is great. I would very much love to not have to wrap everything in Context and be able to use state runes worry-free. I personally think this issue is super important as it can be difficult to discern where the line of server and client begins and ends when using modern JS frameworks.

[AlbertMarashi]

I will be releasing an easy to use integration for this within the next 24 hrs

[AlbertMarashi]

Check it out, an early version: https://github.com/AlbertMarashi/safe-ssr

[paoloricciuti]

My two cents on this:

1. The usage of runes only for .svelte.{ts|js} was very intentional for various reasons. Specifically and most importantly the ability for the compiler to skip over most of the files from libraries that doesn't actually use runes, the ability to signal to the user that you are still in a special file (just like .svelte does for components) and the ability to not hijack a concept as a whole (let's say tomorrow solid decides to go the same direction as svelte they could create a .solid.ts convention without svelte interfering with their files).
2. The whole proposal seems to add a lot of constraints to the state (only objects and structured-cloneable values) to allow the user to have shared global state. Now I can see the appeal of something like this but tbf most of the times I really don't see the need of a complex system to reassign state between client and server. You can already achieve request segregation in a lot of ways: using a context in a svelte component, using locals between load function and I really struggle to see a use case where I would use a global state over those. Can you provide some?

[AlbertMarashi]

@paoloricciuti well, we already do use lots of global state, such as the page store for example.

1. Performance improvements

A major benefit I received through is increased performance by removing the need to waterfall requests. Here is an example of what I mean.

Imagine we have a client-side request-scoped database database connection (like Supabase, SurrealDB) that we want accessible in +page.ts files. In a typical application, one would add define this into the root +layout.ts file, and access it in deeper-layer routes via the await parent()

Unfortunately, if you have a complex application, this will result in the need to sequentially execute these in SSR requests in a waterfall fashion, leading to slower output and page loads, even if they don't depend on data from the parent, just the database

In my application, I solved this problem through using some of the primitives to associate a unique request-scoped database for each unique request inside of the +hooks.server.ts file. This means that pages that don't depend on eachother can retrieve data in parallel.

2. Assigning & using state before component initialization

Unfortunately other stores are only available before component initialization. Sometimes you want some global state that you want to read and modify before or during page load functions.

Comments

The whole proposal seems to add a lot of constraints to the state (only objects and structured-cloneable values)
Actually, svelte states are only available to objects in .(ts|js) files away, so the constraints are the same there. (My primitives just wraps every state in a { inner: T } to work around this limitation, but usually I will store objects anyways)

Regarding the structured-cloneable values, we could use other approaches such as devalue and allow the use of transformers to support serialising things like classes or other non POJOs.

Specifically and most importantly the ability for the compiler to skip over most of the files from libraries that doesn't actually use runes

True, well after writing my proposal, I realised that .svelte.ts files can be imported into .ts files whilst maintaining reactivity, which I didn't realise so this limitation doesn't exist.