The Render Warden

The incident

The trading dashboard updated prices five times a second — and re-rendered the entire component tree with every tick, because one context provider at the root held everything. The 'fast' framework produced an app that pinned CPUs, spun fans, and stuttered exactly when the data mattered most. The framework wasn't the problem. The casual state architecture was.

Why the obvious approach fails

Modern UI frameworks make rendering cheap enough that nobody thinks about it — until the data gets fast or the tree gets deep, and then render cost compounds silently. The classic failure shape: broad state (one store, one context) touched by high-frequency updates, so every tick invalidates everything, and components re-render not because their data changed but because they're downstream of something that did. Sprinkling memoization afterward is patching a flood with towels. The fix is architectural: state flows one direction, is sliced so components subscribe to exactly what they read, high-frequency data lives in its own narrow channel, and expensive subtrees are memoized deliberately — with render counts measured, because 'feels fine on my machine' is not a performance strategy.

The standard

• +State management is unidirectional and sliced — components subscribe to the narrowest selector that serves them, never to whole stores.
• +High-frequency data (live prices, telemetry, cursors) flows through dedicated channels isolated from app-wide state.
• +Expensive components are memoized deliberately, with stable references enforced — accidental prop identity churn is treated as a defect.
• +Render behavior is measured: data-dense screens carry render-count and frame budgets, verified under realistic update rates.
• +Effects are disciplined: data fetching and subscriptions follow declared patterns, so the render loop can't trigger network storms.

Composes with