svelte/kit-shared-server-state

Dlaczego

A server module is loaded once and lives for every request of every user. let user at the top of +page.server.js or hooks.server.js, set inside load or an action, is read by the next request: one person sees another person's name, cart or token. It works in development with one user and fails in production.

Poprawka

Keep request data inside the function: read the user from event.locals (set it in handle), pass it through the return value of load, and persist anything that must outlive the request in a database or a cookie. A module-level constant (configuration, a client object) is fine; a cache must be keyed and must hold public data only.

Przykłady

// bad: src/routes/cart/+page.server.js
let cart = []
export const actions = { add: async ({ request }) => { cart.push((await request.formData()).get('id')) } }
// good
export const actions = {
  add: async ({ request, locals }) => { await db.cart.add(locals.user.id, (await request.formData()).get('id')) }
}

Źródła

• SvelteKit docs, State management (avoid shared state on the server, no side effects in load)

Przeczytaj w terminalu

npx github:dawidolko/frontend-skills explain svelte/kit-shared-server-state