Hey folks, I’m rebuilding a moderately complex web app UI and I’m trying to decide how far to push local component state before I bite the bullet and move to a global model.
Right now local state keeps things easy to reason about, but I’m seeing failure modes like duplicated logic, weird cross-panel desync, and debugging that feels like chasing ghosts without good observability; going global feels cleaner but risks tight coupling and slower delivery when requirements shift.
Where do you draw the line between state locality and a global model when you’re balancing quality, speed, and incident readiness?
Cross-panel desync is the point where I stop trusting local state.
Keep it local for stuff that dies with the component: open/closed, hover, draft text, a temporary filter chip.
Move it up when two things start to happen:
two panels need the same value at the same time
you need to explain or replay state changes during a bug
In a UI like yours, I’d be especially careful around optimistic updates plus polling or websockets. If each panel tries to patch itself, you get flicker and stale overwrites fast.
I’d still avoid making everything global. Put the shared, coordinated bits in one reducer or store, and leave the rest close to the component that owns it.
