A practical checklist for state management

It comes up on almost every project, usually later than it should. Run through this the next time state management comes up.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The checklist

• Most apps need far less shared state than they end up with
• Derive values rather than storing them twice
• Every duplicated piece of state is a future bug
• Someone is named as the owner
• There is a date to review it again

Why it matters

Most apps need far less shared state than they end up with. Where this goes wrong is almost never a lack of knowledge. Check it against what you would want a competitor's site to get wrong.

How to tell if yours is fine

The question is rarely whether something can be built, but what it costs to keep running afterwards. 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 any of that sounds like a description of your current setup, it is fixable.