Built-In Reactivity

Ephemeral state belongs to one widget — a visibility toggle, the selected tab — and lives in its State behind setState. App state is shared across screens or kept between sessions, like the signed-in user. The password toggle is ephemeral.

ChangeNotifier is a foundation class that holds mutable state outside widgets and calls its registered listeners when notifyListeners() runs. ListenableBuilder subscribes to it and calls setState internally, so only the builder's subtree rebuilds.

Each build() call runs fetchWeather() again and passes FutureBuilder a new Future, so it resubscribes, shows waiting and fires another request. Create the future once in a State field or initState and pass that field.

Provider scopes objects to the widget tree and looks them up by type through BuildContext. Riverpod keeps state in a ProviderContainer, readable without BuildContext and overridable in tests. BLoC turns events into a stream of states: most boilerplate, most explicit.

Move the value into the State of the nearest widget above everyone who reads it, pass it down as constructor arguments, and pass callbacks such as ValueChanged<bool> down so children report changes; the owner updates the value with setState.

The object that created the notifier disposes it, typically a State that created it in a field or initState and disposes it in its own dispose(). ListenableBuilder only removes its listener; disposing a notifier you were handed breaks every other listener.

No. The docs present setState, the built-in notifier and InheritedWidget tools, and community packages, and say the best choice depends on the app and team. The architecture case study uses ChangeNotifier view models with ListenableBuilder, and package:provider for dependency injection.

setState reruns build for that one State, and the widgets it returns update down its subtree; ancestors and siblings are untouched. Keeping state in the smallest widget that needs it keeps each rebuild small, which Flutter's docs call pushing state to the leaves.

ConnectionState is none, waiting, active or done. A FutureBuilder goes none or waiting to done; a StreamBuilder goes waiting, then active per event, then done on close. initialData fills snapshot.data before the first result, without changing the state.

ValueNotifier is a ChangeNotifier holding one value; assigning value notifies only when the new value is not == to the old. Mutating a list in place changes nothing the setter can see, so ValueListenableBuilder never rebuilds.

In RefreshIndicator.onRefresh, assign a new future in setState and return it. FutureBuilder keeps the previous result in snapshot.data while waiting, so the builder shows old data whenever hasData is true and spins only when there is none.

StreamBuilder listens in initState, cancels in dispose, and when given a different stream cancels the old subscription and listens to the new one. A stream created in build() is replaced on each rebuild, restarting the source and resetting to waiting.

GetX bundles reactive state, a global dependency registry and navigation behind context-free calls, so features ship fast with little code. The price is hidden global coupling, test setup against a shared registry, and an all-in-one dependency that is costly to remove.

Put each value in the lowest widget above all its readers and writers that lives as long as the value must. Passing values and callbacks down stops scaling when middle widgets only forward them, or when several routes need the same live data.

Keep the progress in a ValueNotifier<double> owned by the download controller, and wrap only the LinearProgressIndicator in a ValueListenableBuilder. Combine progress with status via Listenable.merge, built once, so each tick rebuilds a few widgets instead of the screen.

Inventory the app's state, weight scope, testability, boilerplate, async needs and team skills, then spike one real flow, such as booking a slot, in the two leading candidates. Record the decision with its reasons, and enforce conventions so five people use it one way.

flutter_redux keeps all app state in one Store changed only by actions through pure reducers: maximum predictability and ceremony. Signals-style packages sit at the opposite end: small reactive values that track who reads them, little boilerplate, very fine-grained rebuilds.

Yes. notifyListeners() calls every listener immediately, in registration order. Called from a build method, the listening builders try to mark themselves dirty mid-build, and unless they are descendants of the widget building, debug mode throws 'setState() or markNeedsBuild() called during build.'