Photo by Ferenc Almasi on Unsplash

Let’s Talk About State Management in Svelte

State management is an important thing to get right when you’re building an app. State in Svelte is a little different from the other big frameworks, I’ll be comparing it to React since that’s where I have the most experience building large apps.

Reactivity

Svelte is relatively unopinionated about state management, and embraces reactivity. Basic state updates are done with variable reassignment, which initially feels strange coming from React, where let is a rare sight. Here’s an example in Svelte:

Clicking that button will update movies, which will then cause otherMovies to update but NOT moreMovies. Only variables defined with the reactive $: syntax (which is valid but arcane JavaScript) will update on re-render, variables defined with const don’t. This is quite different from React, where variables update on every render unless they’re inside useEffect (and the dependencies don’t change).

The $: syntax actually works a bit like useEffect in React: anything defined with $: will update when its dependencies change, but the dependencies don’t need to be passed in — they’re automatically detected based on the variables in the definition. No useEffect dependency array, no insistent ESLint warnings.

After the initial learning curve, this is a really pleasant experience. You update state and the changes cascade through your reactive variables without needing to manage extra re-renders yourself. For all that’s been said about React’s declarative model (I’ve said it myself!), this feels far more declarative than useEffect.

Data binding

Svelte also has two-way data binding. This is great for reducing boilerplate with inputs and forms, but as soon as I started using it my spidey sense started tingling.

Someone nearby is using two-way data binding!

The word footgun gets used a lot with two-way data binding, here’s why: two-way data binding allows (encourages?) pushing state management out into the edges of your app. Rather than a single source of truth or multiple localized sources, you have bits of state spread throughout your app affecting each other with no clear communication pattern. Imagine some state at the root of your app:

Bind to as many components as you like, go nuts!

Somewhere deep in your component tree you have a component with a movies prop. Two-way data binding means when you update state in that component…

…it updates locally but also updates the original state and propagates the change everywhere else. Good luck keeping track of that.

This indirect management of state is problematic, but the real fun starts when you need to make updates to your data shape. When knowledge of the data shape creeps down into all the nooks and crannies of your app, it becomes cumbersome to change because you need to change every instance where that shape is used. The implementation becomes coupled with the data shape, and changes often mean you need to rework big chunks of your app.

Here’s a simple example: Your app was designed for a single user, so you have everything at the top level:

const state = {
  movies: [ ... ],
  reviews: [ ... ],
  favorites: [ ... ],
};

But someone hears about your app and they want in. Multiple users! Great, we’ll just update this state here…

const state = {
  me: {
    movies: [ ... ],
    reviews: [ ... ],
    favorites: [ ... ],
  },
  you: {
    posts: [ ... ],
    reviews: [ ... ],
    favorites: [ ... ],
  }
};

…and now you have to go update all the components that expect the state to be in the first shape. Hope you find them all!

Taking the time to design your state before you start will help, but over the lifetime of an app there will always be surprises. Resilient architecture optimizes for change, and a good way to do that is with encapsulation and clear interfaces. This is absolutely possible with Svelte, but you have to be intentional about it.

The React way

React also allows you to directly manipulate state from anywhere, but it’s not a common pattern and the data flow is clear. It’s an example of the pit of success, where it’s harder to do the wrong thing. In order to intertwine the data shape into the far reaches of your app you would have to pass setState down through layers of props, but the more common pattern is to create an interface by defining a handler alongside the state and passing that handler down.

Reducers makes this even clearer if they’re used correctly. Redux has its downsides, but one thing it gets right is separation of concerns. It encourages state management in one place (the reducer) with components sending messages (actions) about what the user did instead of how the state should update. How declarative!

Let’s head back to Svelte land. State management is a bit “anything goes,” leaving it up to the user to decide. This requires some experience to make the right choices, but the good news is Svelte is flexible. Even though it doesn’t work like React by default, it allows for the same patterns.

Svelte has stores, which are similar to useState, where you use set and update functions to set state. You can create a clean interface by exposing handlers instead of set/update directly. Svelte doesn’t include a reducer equivalent, but using a writable store you can create a basic useReducer in fewer than ten lines:

Svelte stores let you subscribe to updates, and in fact you can give a subscribe method to anything to turn it into a store. Our new store can be used like this:

That $store syntax is shorthand access to subscribe to the store, changes will propagate automatically.

The takeaway

I don’t know if I prefer React patterns because they’re objectively better, or if it’s just because I’m comfortable managing complex state using these patterns. I’m keeping an open mind that Svelte might have a clean and totally different way of managing state for large applications.

Another thing to keep in mind: this really is only an issue for large apps. For smaller apps the Svelte pattern of reactive values and let reassignment works fine. But at what point does a small app become a large one? Do you always know ahead of time, or do you open up your laptop one day and realize you’ve woven yourself into a tangled web? I like to plan for change and I like to look for ways to keep concerns separate.

You can even mix these patterns, holding some state in a reducer with reactive values derived from that state:

Mmmmmmovies!

Is this a good idea? I’m not really sure yet. React’s guardrails make it easy to do the right thing (or at least harder to do the wrong thing), but it could also be that so much has been written about React state management, and Svelte is still young enough that clear patterns have yet to emerge.

Also, a note about two-way data binding: like class inheritance, it’s not intrinsically bad, it’s just been through some abuse. It’s real nice not to have all the boilerplate around inputs and forms, you just need to use it wisely. Similar to limiting inheritance, it’s a good idea to limit the number of layers you’re binding through (i.e. bind directly to the HTML elements rather than to other Svelte components).

One more interesting thing is how Svelte and React differ in their opinions. Svelte seems to be opinionated on things like CSS and accessibility, and less so with state management, where React is the reverse. Personally I’m comfortable with the flexibility in state management (and I’m happy to let the framework make some CSS decisions), but I think it might lead newcomers down a path where things get intertwined, which could leave some people with a negative experience.

Or maybe not! These are just some observations I found interesting while working with Svelte on some projects that have grown in complexity. I haven’t made up my mind yet, but my experience with Svelte so far has been so positive that I’m really looking for ways it can scale. I see a lot of promise, and I want it to be as good as its potential.