Flutter Widget Communication and State Management: Techniques and Principles

Flutter is widely used in internet companies, yet many developers lack a systematic understanding of widget communication and state management.

The article covers three main areas: parent‑to‑child widget communication, communication across multiple widgets or pages, and state management.

1 Parent‑to‑Child Communication : there are four ways—direct value passing, passing a function, modifying the child’s Key, and using a GlobalKey.

1.1 Direct value passing: the parent supplies values through the child’s constructor.

1.2 Function callback: the parent passes a function object via the child’s constructor; the child invokes it to call back to the parent.

1.3 Modifying the Key: changing the child’s Key forces the framework to rebuild the child’s Element and State. For StatelessWidget this works via the constructor; for StatefulWidget, setState alone does not change internal state, so altering the Key triggers a State rebuild.

The framework’s canUpdate method compares widget type and Key; if they differ, the Element is rebuilt. ValueKey overrides == to compare its value.

1.4 GlobalKey: a GlobalKey is created and assigned to the child. The parent can obtain the child’s State via globalKey.currentState and invoke methods on it. During Element.mount, if the widget’s key is a GlobalKey, the pair (key, element) is stored in GlobalKey’s static _registry map; on unmount the entry is removed. The GlobalKey’s currentState returns the associated Element’s state.

2 Cross‑Widget/Page Communication : passing data layer‑by‑layer is tedious and creates tight coupling. State management tools provide a better solution.

3 State Management : it is the centralized distribution of data state; when data changes, all dependents update—an implementation of the observer pattern.

3.1 InheritedWidget: Flutter’s observer‑pattern element. Each Element holds a reference to its Widget. The flow diagram shows a registration (blue) and refresh (green) process. Source analysis: context.inheritFromWidgetOfExactType looks up the InheritedElement in the _inheritedWidgets map and returns the requested widget. The _inheritedWidgets map is passed down from parent elements during mount and is initially created by InheritedElement. When a widget calls inheritFromWidgetOfExactType, its Element is added to the InheritedElement’s _dependents map. If updateShouldNotify returns true, all dependents receive didChangeDependencies, which triggers markNeedsBuild and eventually a rebuild.

3.2 Stream: Dart’s built‑in observer pattern, focusing on broadcast streams. A broadcast StreamController creates a _BroadcastStreamController whose stream is a _BroadcastStream. Listening creates a _BroadcastSubscription, a doubly‑linked list node held by the controller. Adding an event traverses the subscription list and invokes the stored callbacks. Synchronous adds call the callbacks directly; asynchronous adds schedule a microtask via scheduleMicrotask.

3.3 EventBus: a thin wrapper around Dart’s broadcast Stream, providing a familiar publish‑subscribe API similar to Android’s EventBus.

3.4 Bloc: encapsulates a Stream (or InheritedWidget) and follows MVVM architecture. It can be used globally for state management or locally as a view‑model.

3.5 Scoped_model: wraps InheritedWidget with an MVVM approach, usable globally or locally.

3.6 Provider: also wraps InheritedWidget, follows MVVM, is easier to use, and is officially maintained by Google.

3.7 Redux: wraps InheritedWidget; its setup is relatively verbose, so it is generally not recommended for typical Flutter apps.

4 Summary : For parent‑child communication use the four direct techniques. For communication across many widgets or pages, employ a state management solution. InheritedWidget and Stream are the foundational primitives; other solutions (Bloc, Scoped_model, Provider, Redux, EventBus) are essentially wrappers around these two.