Állapotkezelés és az SSR-csapdák

6.1Hova tartozik ez az adat?

Vue SPA-ban egy helyre szokott kerülni minden: a store-ba. SSR mellett ez pazarlás és hibaforrás egyszerre, mert sok „állapot” valójában nem állapot. Mielőtt bármit useState-be tennél, fusd át ezt:

6.2useState a gyakorlatban

// app/composables/useCurrentUser.ts
export const useCurrentUser = () => {
  // az initializer CSAK akkor fut, ha ehhez a kulcshoz még nincs érték
  return useState<User | null>('auth:user', () => null)
}

Három dolog, amit érdemes tudni róla:

• A kulcs globális. Az egész alkalmazásban egy névtér. Ha két helyen véletlenül ugyanaz a 'user' kulcs, ugyanazt az állapotot használják. Prefixálj: 'auth:user', 'ui:sidebar', 'tenant:current'.
• Szerializálhatónak kell lennie. Az érték átmegy a payloadon, ezért Date, Map, Set, BigInt rendben van — függvény és osztálypéldány nem. Ha osztályt teszel bele, a kliensen sima objektumként ébred fel, metódusok nélkül.
• A payloadba kerül. Vagyis ugyanaz a szabály él rá, mint az 5. modulban: amit useState-be teszel a szerveren, azt a felhasználó látja a HTML forrásában. Ne tegyél bele belső mezőt.

// „store" Nuxt-módra — nem kell hozzá könyvtár
export const useSidebar = () => {
  const open = useState('ui:sidebar', () => true)
  const toggle = () => { open.value = !open.value }
  return { open, toggle }
}

// takarítás — például kijelentkezéskor vagy tenantváltásnál
clearNuxtState(['auth:user', 'tenant:current'])

6.3Cross-request state pollution — az anatómia

Ez a modul lényege. A 3. modulban már felvillantottuk; most nézzük meg, miért történik, és hol bújik el.

Miért nem veszed észre?

Mert a hiba eltűnik, amikor keresed. Fejlesztés közben egyedül vagy: egy kérés, egy állapot, minden rendben. Az első éles napokon is működhet, ha kevés a forgalom, és az izolátum kérések között „kipiheni magát”. Aztán jön egy nap, amikor két felhasználó egyszerre kattint, és valaki más adatait látja.

A három rejtekhely

// app/composables/useFilters.ts
const filters = reactive({ status: 'active' })   // ✗ minden kérés ugyanezt írja
export const useFilters = () => filters

// server/utils/context.ts
let currentTenant: Tenant | null = null            // ✗ a legveszélyesebb változat

export function setTenant(t: Tenant) { currentTenant = t }
export function getTenant() { return currentTenant }

Ez a második a legrosszabb, mert kényelmesnek tűnik („ne kelljen mindenhova átadni az event-et”), és mert szerveroldalon van, ahol a valódi adat lakik. Két párhuzamos kérésnél az egyik felülírja a másik tenantját, és a lekérdezések a rossz tenanttal futnak le. A helyes megoldás a 4. modulból: event.context.tenant, és az event-et végig átadod.

// server/utils/settings.ts
let cached: Settings | null = null

export async function getSettings(event) {
  if (!cached) cached = await loadSettings(event)   // ✗ melyik tenanté?!
  return cached
}

A cache önmagában nem baj — de a kulcsának tartalmaznia kell mindent, amitől az érték függ. Ha tenantonként más, akkor Map<tenantId, Settings> kell, és még akkor is korlátos élettartammal. A jó megoldás általában nem is memóriában van: KV vagy a Nitro cache-rétege, tenantra kulcsolva (18. modul).

Mit szabad modul-szinten tartani?

Hogyan találod meg?

1. Kódszabály: a server/ alatt és a composables/-ben ne legyen olyan let, reactive() vagy ref() a fájl tetején (export-függvényen kívül), ami nem konstans. Ezt code review-ban kell nézni — lintszabállyal is kikényszeríthető.
2. Teszt párhuzamos kérésekkel: két különböző tenanttal, egyszerre indított kérés, és nézd, hogy mindkettő a sajátját kapja-e. Egy egyszerű Promise.all két $fetch-csel már kimutatja a durva eseteket.
3. Preview-környezetben, valódi Workers-runtime alatt. Lokálisan, Node-ban ritkán reprodukálódik — a 2. modul dev-vs-prod táblája erről szólt.

6.4Mikor kell tényleg Pinia?

A Pinia jó könyvtár, és a @pinia/nuxt modullal SSR-biztos: a store-ok kérésenként példányosulnak, az állapot a payloadon keresztül jut a kliensre. Nem kell félni tőle — csak nem az első választás.

6.5Cookie-alapú állapot: useCookie

Emlékszel a 3. modul hydration-táblájából a localStorage-sorra? Ez a megoldás rá. A cookie a kéréssel együtt utazik, tehát a szerver már az első rendereléskor látja — nincs eltérés a szerveri és a kliensi kimenet között:

// app/composables/useTheme.ts
export const useTheme = () => {
  return useCookie<'light' | 'dark'>('theme', {
    default:  () => 'light',
    maxAge:   60 * 60 * 24 * 365,
    sameSite: 'lax',
    secure:   true,
    path:     '/',
  })
}

// használat — reaktív ref, írásra a böngésző cookie-ját is frissíti
const theme = useTheme()
theme.value = 'dark'

Amire figyelj:

• httpOnly cookie-t a kliensen nem tudsz olvasni — ez a session helyes beállítása, de akkor a useCookie csak szerveroldalon ad értéket. Ez szándékos: a session ne legyen JS-ből elérhető.
• Minden cookie minden kérésben utazik. Ne tegyél bele nagy objektumot: lassítja az összes kérést, és a fejléc-méretnek is van felső határa.
• Multitenantnál a domain beállítás dönt. Ha aldomain-modellben a szülő-domainre sütöd, minden tenant aldomainje látja (4. modul). Ez lehet szándékos (közös bejelentkezés), de nem lehet véletlen.

6.6Az URL is állapot

Szűrők, rendezés, lapozás, kijelölt fül: ezek majdnem mindig az URL-be valók, nem useState-be. Négy dolgot kapsz ingyen: megosztható linket, működő vissza-gombot, azonnal helyes SSR-t, és cache-elhetőséget.

<script setup lang="ts">
const route  = useRoute()
const router = useRouter()

// az URL az igazság forrása
const status = computed({
  get: () => (route.query.status as string) ?? 'active',
  set: (v) => router.replace({ query: { ...route.query, status: v, page: undefined } }),
})

// és a lekérés egyszerűen követi
const { data: projects } = await useFetch('/api/projects', {
  query: { status },
  key: () => `projects:${slug.value}:${status.value}`,
})
</script>

6.7Állapot a tenant-határon

Ha az appodban lehet tenantot váltani anélkül, hogy teljes oldalújratöltés történne, akkor a váltás egy invalidálási esemény: minden tenanthoz kötött állapotot és lekért adatot el kell dobni.

export async function switchTenant(slug: string) {
  // ① minden tenanthoz kötött kliensállapot törlése
  clearNuxtState(['tenant:current', 'ui:recent', 'billing:summary'])

  // ② a lekért adatok eldobása — ha a kulcsaid tenant-prefixesek, célzottan is megy
  await clearNuxtData((key) => key.includes(':'))

  // ③ és a navigáció — aldomain-modellben ez amúgy is teljes újratöltés
  await navigateTo(`/t/${slug}`)
}

6.8Ellenőrizd magad