Question 1

Which part of state do you keep inside a widget and which do you lift out? How do you decide?

Accepted Answer

Structure the answer around three questions: who reads it, how long must it live, how is it tested. If only one widget and its subtree read it, its lifetime equals the screen's, and a widget test covers it — setState or a ValueNotifier is enough. If two distant screens read it, it must survive the screen being disposed, or it must be unit tested without a UI — I lift it out. Finish with a concrete example: "In my last project the search query stayed inside the screen, while the filter selection moved into its own notifier because two screens shared it." Adding the docs' own caveat lands well: there is no universal rule, and sometimes a refactor is needed.

Question 2

A junior developer keeps all state in a single global store. What would you say in code review?

Accepted Answer

Don't stop at "don't do that" — show the concrete cost: Performance: every change in the global store wakes every widget bound to it; frequently changing state like a scroll offset or a text field makes that expensive. Lifetime: closing a screen no longer clears its state — the user comes back to a stale selection, a real source of bugs. Testing: once ephemeral state is global, tests leak into each other and every test needs to reset the store. Then propose the split: form and animation state stays in the widget, only shared, session-lived state goes into the store.

Question 3

Tell me about a time ephemeral state had to become app state.

Accepted Answer

This is an experience question — structure it as starting point → new requirement → what I changed → outcome. Example: "Filters lived in the screen's State. Then a requirement arrived that filters must survive an app restart and that a deep link from a push notification should open with a filter applied. I moved the filter into a repository and the screen became a pure reader; the migration took a day because the filter model was already immutable and passed around with copyWith." Close with the lesson: lifting state out is easy with an immutable model and painful with a mutable one.

Question	Ephemeral	App state
Who reads it?	One widget and its subtree	Screens far apart in the tree
What happens when the widget is disposed?	It is lost — and that is fine	It must survive
Typical tool	`setState`, `ValueNotifier`	Provider / Riverpod / BLoC
How it is tested	Through a widget test	A separate unit test, independent of the UI

Ephemeral state vs app state

📚 Sources and documentation