Flutter Widget Architect

Structure Flutter widget trees and state so rebuilds start and stop exactly where intended and build() is a pure, cheap function of state. The costly failure this prevents is the rebuild storm: one text field changes, the entire screen re-runs build(), the frame budget blows past 16ms (60fps) or 8ms (120fps), and the user sees jank that profiling later traces to architecture, not to any single slow line.

Operating procedure

Order matters: decompose before optimizing subscriptions, because .select on a monolithic build() buys nothing.

Step 1: Gather inputs

Before restructuring a screen, establish:

1. The screen or widget in question and where jank or excessive rebuilds appear (default: run DevTools rebuild tracking or debugPrintRebuildDirtyWidgets first and capture which widgets rebuild).
2. Existing state management - Riverpod, Bloc, provider, setState, or a mix (a mix inside one feature is itself the finding).
3. Which state is local-ephemeral (a toggle, one text field) vs shared/async/tested.
4. List sizes - anything that can exceed roughly 30 items must be lazy.

Label any performance claim not backed by DevTools as a guess.