You just got to be careful to never touch the global store from SSR!

conditionally returned either a readable store (from SSR) or a global writable store (from CSR) to make things like real time updates via WebSockets possible - although that solution does have one big advantage: the global store is always there.

One pattern that I love to use in my SvelteKit projects is returning writable stores from the layout’s load function. This makes it possible to fetch data from the server (for example the user object for the logged in user), and then you make this object available as a writable reactive store throughout the whole application. So when the user updates their username or avatar, you do the PUT request to the server and you get the updated user object back from the server as the response, you can simply update the $user writable store value and every place in your app where you show the user object gets updated immediately.

I personally abstract everything away into stores. Stores are amazing. With everything I mean things like fetch, Worker or WebSocket.

export const fibonacci = function (n, initialData) { return readable( { loading: true, error: null, data: initialData, }, (set) => { let controller = new AbortController(); (async () => { try { let result = await fibonacciWorker.calculate(n, { signal: controller.signal }); set({ loading: false, error: null, data: result, }); } catch (err) { // Ignore AbortErrors, they're not unexpected but a feature. // In case of abortion we just keep the loading state because another request is on its way anyway. if (err.name !== 'AbortError') { set({ loading: false, error: err, data: initialData, }); } } })(); return () => { controller.abort(); }; } ); };

Yes I love stores.

const unsubscribe = errorStore.subscribe(value => { if (!value) { return } error = value errorStore.set() })

All my stores also have a defaultValue property and reset method

I've said it multiples times and I say it again: in Svelte stores solve all your problems and I love them so much.

I ended up writing a custom store that "buffers" sets for both a small time interval and ensuring only one async action is in flight (and triggering an extra round of async processing if a set was seen after the last async action was launched).

In effect, the $ syntax we've seen above will actually setup a subscription to the store. And the subscription will be cancelled when the component is destroyed. If the store is subscribed by multiple components, the store will be disposed only when the last component unsubscribes (it will be reinitialized, if a new subscription is made). This is very handy to manage the lifecycle of disposable things in your code.

lifecycle is also managed automatically by Svelte

(And we've covered 75% of the store topic... They're efficient, to the point... And simple!)

In order to use this, we need to use a little more advanced readable store. Here's your example updated for this:

In your Svelte component, you can then use your store with the special $ prefix syntax, to access the value of the store ('cause the temperature variable is a reference to the store itself, it's just a mean to our end, the result we need is the value):

// our temperature is now a store with initial value 0 const temperature = writable(0); // now we don't need to change this function, the change will be propaged // by the store itself const getTemperature = () => { return temperature; }

Here's how we would rewrite our callback example with a store instead:

Same as our callback example, except they offer a handful of other very useful tool (like computing derived values from other stores), and also a slick syntax in the Svelte component.

Stores are essentially some kind of simplified streams (or Observable as they're called in ES), that is they represent a value over time.

QueueStore

For me however, things get really interesting with the creation of “custom” stores. The creators of Svelte were/are obviously well aware of the power and flexibility of these stores and have provided a simply interface to adhere to. Basically, any object that implements the “subscribe” method is a store!

One of the (in my opinion) most useful components of the Svelte library is that of “stores”.

What I like is that currentUser isn't a value, it's a store, and therefore you have full control over how you deal with it.

Talking of context, that's much closer to the approach I take with Svelte and use a writable store.

The more I think about this, the more I think that using the context API (for all the stores — page, preloading and session) is the most regret-proof approach, using the proposal above

session can be used to pass data from the server related to the current request. It is a writable store, meaning you can update it with new data. If, for example, you populate the session with the current user on the server, you can update the store when the user logs in. Your components will refresh to reflect the new state

Just realised this doesn't actually work. If store is just something exported by the app, there's no way to prevent leakage. Instead, it needs to be tied to rendering, which means we need to use the context API. Sapper needs to provide a top level component that sets the store as context for the rest of the app. You would therefore only be able to access it during initialisation, which means you couldn't do it inside a setTimeout and get someone else's session by accident:

It's really helpful that Svelte stores are easy to use in plain JS. We can change a state store over completely to Svelte and make the Angular components subscribe to that store as well without needing to maintain and sync 2 copies of the state.

Stores are such an amazing abstraction.

This subscription function must be immediately and synchronously called with the store's current value upon calling .subscribe. All of a store's active subscription functions must later be synchronously called whenever the store's value changes.

Assignments to $-prefixed variables require that the variable be a writable store, and will result in a call to the store's .set method.

Here's a proxy store I wrote to derive the value of a store nested within other stores, it plays nice with typescript and can go infinitely deep

Generally, you should read the value of a store by subscribing to it and using the value as it changes over time. Occasionally, you may need to retrieve the value of a store to which you're not subscribed. get allows you to do so.

Using another reactive statement with $effect we have Svelte automatically handle subscribing and unsubscribing to the store

One thing I considered was abusing a custom store for this kind of thing.

const store = readable(machine.initialState, set => { service.subscribe(state => { if (state.changed) set(state) }) service.start() return () => { service.stop() } })

The readable store takes a function as a second argument which has its own internal set method, allowing us to wrap any api, like Xstate or Redux that has its own built in sub­scrip­tion model but with a slightly different api.

Indeed, this simple contract is very close to that of an ob­serv­able, such as those provided by Rxjs. set is basically equiv­a­lent to next in the ob­serv­able world.

The $ contract for auto-sub­scrib­ing is lovely in its sim­plic­ity and flex­i­bil­ity. You can adapt your own preferred state-man­age­ment pattern or library, with or without Svelte stores as helpers. Svelte does not fuss about how you want to manage your state.

Arguably what is in­ter­est­ing about Svelte’s approach to state man­age­ment is not the store itself but the auto-sub­scrip­tion that is possible because of the Svelte compiler. By simply appending a $ to a variable inside of a component, e.g. $myVariable, the compiler will know to expect an object with a subscribe method on it and generate the boil­er­plate of sub­scrib­ing and un­sub­scrib­ing for you.

setClient(writable(apolloClient)); let client getClient().subscribe((_client) => client = _client);

setContext / getContext can only be used once at component init, so how do you share your API result through context? Related: how would you share those API results if the call was made outside of a Svelte component, where setContext would be even more out of the question (and the API call would arguably be better located, for separation of concerns matters)? Well, put a store in your context.

This is pretty good, but I don’t love that $contactStore.length bit. If we wanted to change the shape of the store from an array to a key-value store or something, we’d have to remember to update this component too. Instead, we can define a new derived store: contactCountStore. It’ll always track the count, which lets this component have less knowledge about the structure of the store. That refactor looks like this:

I used a "specific function". But maybe it could be done within a derived store. A kind of auto reset on ... But I think there is no elagant solution, so I stick with the specific function.

You're not limited to using $count inside the markup, either — you can use it anywhere in the <script> as well, such as in event handlers or reactive declarations.

$: console.log(`the count is ${$count}`);

Stores are global state. While context is local state.

Notice it's not related to components. Another crucial difference is that it's accessible from outside of components. And good way to determine where goes where is to ask yourself, can this particular state and functionality still makes sense outside of the displayed component?

In fact, you might use the two together. Since context is not reactive, values that change over time should be represented as stores:

For interoperability with RxJS Observables, the .subscribe method is also allowed to return an object with an .unsubscribe method, rather than return the unsubscription function directly.