On most SSR environments using the store directly – as you would in plain Svelte Apps – means localisation state is unintentionally shared between users.
For most smaller applications this doesn't have any visible effect because localisation state is set at the beginning of the request and the request is completed before another user's request is received.
But in high traffic environments and / or slow rendering pages the following could happen:
User A has a locale en. State is set, the page starts rendering with locale en.
While user A's request is still being rendered on the server, User B makes a request with a different locale, say cn. This modifies the global locale state.
User A's request will now finish rendering with locale cn!
NishuGoel
commented
1 year ago
This PR adds instructions for the use with sveltekit that avoids a tricky caveat regarding the way that Sveltekit uses stores on serverside:
On most SSR environments using the store directly – as you would in plain Svelte Apps – means localisation state is unintentionally shared between users.
For most smaller applications this doesn't have any visible effect because localisation state is set at the beginning of the request and the request is completed before another user's request is received.
But in high traffic environments and / or slow rendering pages the following could happen:
en. State is set, the page starts rendering with localeen.cn. This modifies the globallocalestate.cn!The Sveltekit docs explicitly state to avoid global stores for this reason: https://kit.svelte.dev/docs/state-management
Fortunately this library uses i18next's
createInstancefunction, so the fix is as easy as just usinggetContextinstead of using the store directly.