Getting started with state management
Teams tend to reach for this after something has already gone wrong. A short on-ramp to state management for teams who have not touched it before.
Code gets read far more often than it gets written, and usually by someone with less context than the author had. If two people in the business would answer this differently, that gap is the actual problem.
What is actually at stake
Most apps need far less shared state than they end up with. Small and consistent beats large and occasional here. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Your first week
- Find out what is already in place
- Derive values rather than storing them twice
- Change one thing and measure it
Every duplicated piece of state is a future bug. That sounds obvious written down. It is still the thing most often skipped. Check it against what you would want a competitor's site to get wrong.
In practice
Most development decisions are really maintenance decisions wearing a different hat. 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
Worth checking on your own setup before it becomes someone else's problem to fix.