Question 1

Walk through the StatefulWidget lifecycle in order.

Accepted Answer

The order: createState → initState (once: controllers, subscriptions, the first load) → didChangeDependencies (where InheritedWidget dependencies are read) → build → didUpdateWidget when the parent updates → build → finally dispose. Explain each by what it is for, not as a definition. Name the two traps: you cannot read InheritedWidgets from context in initState, and initState itself cannot be async. Close with the mounted check — async work can return after dispose.

Question 2

What happens under the hood when you call setState?

Accepted Answer

Two steps: the callback runs synchronously, so the state changes immediately, and then the element goes onto the dirty list. On the next frame Flutter collects the dirty elements, calls their build and diffs the result against the old widget tree. Two practical consequences: (1) awaiting inside setState is pointless because the callback is synchronous — fetch first, then call setState; (2) several setState calls in a row are not expensive, because they coalesce into a single rebuild on the same frame.

Question 3

What causes "setState called after dispose" and how do you prevent it?

Accepted Answer

The cause: an async operation — a request, a timer, a stream — completes after the widget has left the tree and calls setState on a State that is already disposed. Three layers of prevention: (1) if (!mounted) return; after every await; (2) cancelling subscriptions and timers in dispose(), which removes the root cause; (3) a cancellation token for requests that support one. The mounted check is the simplest guard but not sufficient alone: an uncancelled subscription keeps running and consuming resources.

Question 4

When is setState not enough and you need something else?

Accepted Answer

Three signals. (1) The same state is needed on several screens — a cart, authentication. Passing it with setState turns into props drilling. (2) The state must outlive the widget — it should not vanish when the screen closes. (3) Business logic is mixed into the UI, which makes it hard to test. Those are the cases for Provider/Riverpod/BLoC. But I would state the converse too: for state local to one screen — a form, an expandable panel, a counter — setState is the right choice, and moving everything into a state-management package is needless complexity.

Method	When it runs	What it is for
`initState`	Once, when the State is created	Creating controllers, opening subscriptions, kicking off the first load
`didChangeDependencies`	After `initState`, and whenever an InheritedWidget it depends on changes	Work that depends on `Theme.of` or `MediaQuery.of`
`didUpdateWidget`	When the parent supplies a new widget of the same type	Comparing old and new `widget` parameters and reacting
`dispose`	When the State leaves the tree for good	Closing controllers, cancelling subscriptions

setState and the StatefulWidget lifecycle

📚 Sources and documentation