State & Lifecycle
In React, state lives inside the component — either as a useState hook variable or as this.state in a class component. When state changes, React re-renders the component function (or calls render()).
Flutter separates the concern differently. A StatefulWidget is the immutable configuration object (like your props/JSX tag), and a companion State<T> class holds the mutable state and owns the build() method. The two work as a unit: the widget provides identity and configuration; the state provides memory and lifecycle.
Why the split?
Section titled “Why the split?”Flutter’s widget tree is rebuilt very frequently — any ancestor rebuild can recreate widget objects. If state lived on the widget itself it would be destroyed on every rebuild. By keeping state in a separate, longer-lived State object that Flutter manages, the widget description can be cheaply recreated while state survives across rebuilds.
| React concept | Flutter equivalent |
|---|---|
useState / this.state | fields on the State<T> class |
setState(newVal) | setState(() { field = newVal; }) |
Component function / render() | State.build(BuildContext) |
useEffect(fn, []) — mount | initState() |
useEffect(fn, [dep]) — prop change | didUpdateWidget(oldWidget) |
useEffect(() => cleanup, []) — unmount | dispose() |
useContext / React Context | InheritedWidget / BuildContext |
React key prop | Flutter Key on a widget |
Module lessons
Section titled “Module lessons”- State & Lifecycle overview ← you are here
- setState vs useState — the mutable state API
- build() vs render() — Flutter’s pure rebuild model
- The lifecycle in depth —
initState,didChangeDependencies,didUpdateWidget,dispose - Rebuilds & Keys —
constwidgets, identity, and reconciliation