Before you invest in state management

The advice here is unglamorous, which is probably why it gets skipped. Before you spend anything on state management, it is worth confirming a few things are already true.

The question is rarely whether something can be built, but what it costs to keep running afterwards. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Most apps need far less shared state than they end up with
• You have a way to tell whether it worked

The mistakes we see most

Derive values rather than storing them twice. Getting it slightly wrong is survivable. Ignoring it entirely is not. If it only works because one person remembers to do something, it does not work yet.

Every duplicated piece of state is a future bug. This is the sort of thing that compounds, quietly, in both directions. Check it against what you would want a competitor's site to get wrong.

What this looks like day to day

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about state management before you move on:

• Someone can say what the current setup is without going to look
• Derive values rather than storing them twice — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.