Flutter provides several ways to manage state, ranging from simple built-in approaches such as setState() to more structured solutions such as Provider, Riverpod, and Bloc/Cubit. Understanding when each approach is useful helps developers avoid unnecessary complexity while keeping applications maintainable and scalable.
There is no single state management approach that is correct for every application. The appropriate choice depends on the type of state, how many widgets need it, application complexity, asynchronous requirements, testing needs, team experience, and the architecture of the project.
State is data that can change during the lifetime of an application and can affect what the user sees or how the application behaves.
State management is the process of storing, updating, sharing, and reacting to that changing data.
User Action
↓
State Changes
↓
Flutter Notifies Relevant UI
↓
Widget Rebuilds
↓
Updated UIDifferent applications have different state management requirements. A simple screen may only need a single integer or Boolean value, while a large application may need authentication state, API data, caching, repositories, asynchronous operations, and shared state across many screens.
Flutter's documentation describes multiple valid approaches, including setState(), ValueNotifier, InheritedWidget, and community packages. The choice depends on the complexity and nature of the application and the needs of the development team.
Before selecting an approach, determine which widgets or features need access to the state.
If only one widget needs the state, local state management is usually appropriate.
Single Widget
↓
Local State
↓
setState()If multiple related widgets need the same state, the state can often be moved to their common parent.
Parent
/ \
↓ ↓
Child A Child B
\ /
Shared StateIf state is shared across different screens or application features, a dedicated state management approach can provide better organization.
App State
/ | \
↓ ↓ ↓
Screen Screen ScreenOne of the most useful distinctions is between ephemeral state and application state.
Ephemeral state is generally local to one widget or a small part of the UI.
Examples include:
Flutter documentation identifies State and setState() as a natural approach for this kind of widget-specific state.
Application state is state that may need to be shared across different parts of the application.
Examples include:
The distinction is not absolute. A value that starts as local state can become application state as application requirements change.
setState() is Flutter's basic approach for updating state owned by a StatefulWidget.
class CounterPage extends StatefulWidget {
const CounterPage({super.key});
@override
State createState() => _CounterPageState();
}
class _CounterPageState extends State {
int count = 0;
void increment() {
setState(() {
count++;
});
}
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Count: $count'),
ElevatedButton(
onPressed: increment,
child: const Text('Increment'),
),
],
);
}
} Flutter's documentation describes setState() as a low-level approach for widget-specific, ephemeral state.
Lifting state up means moving state from a child widget to a common parent so multiple children can access and modify it through properties and callbacks.
class ParentWidget extends StatefulWidget {
const ParentWidget({super.key});
@override
State createState() => _ParentWidgetState();
}
class _ParentWidgetState extends State {
bool isSelected = false;
@override
Widget build(BuildContext context) {
return Column(
children: [
Checkbox(
value: isSelected,
onChanged: (value) {
setState(() {
isSelected = value ?? false;
});
},
),
Text(
isSelected ? 'Selected' : 'Not Selected',
),
],
);
}
} Flutter's interactivity guidance describes parent-managed state as useful when the state represents user data such as checkbox or slider values, while aesthetic state such as animation state can remain inside the widget.
ValueNotifier is useful for small pieces of reactive state where you want listeners to respond when a value changes.
final ValueNotifier counter = ValueNotifier(0);
ValueListenableBuilder(
valueListenable: counter,
builder: (context, value, child) {
return Text('Count: $value');
},
); Flutter lists ValueNotifier and InheritedNotifier among its built-in state management approaches.
InheritedWidget is a lower-level Flutter mechanism for communicating data from ancestors to descendants in the widget tree.
Ancestor Widget
|
↓
InheritedWidget
|
↓
Child Widget
|
↓
Grandchild WidgetFlutter identifies InheritedWidget and InheritedModel as low-level approaches, and notes that Provider and many other approaches use these mechanisms under the hood.
Provider is a package that simplifies exposing and consuming objects through the widget tree. It is commonly used with ChangeNotifier.
class CounterModel extends ChangeNotifier {
int count = 0;
void increment() {
count++;
notifyListeners();
}
}ChangeNotifierProvider(
create: (_) => CounterModel(),
child: const MyApp(),
)final counter = context.watch();
Text('Count: ${counter.count}'); Provider reduces boilerplate around Flutter's inherited-widget mechanism and offers common ways to consume and listen to shared objects.
ChangeNotifier.InheritedWidget.Riverpod is a provider-based solution for state and dependency management. It provides different provider types for different requirements, including simple state, asynchronous results, and streams.
| Provider | Useful For |
|---|---|
| Provider | Services, computed values, and read-only dependencies |
| StateProvider | Simple values such as filters, strings, Booleans, and numbers |
| FutureProvider | Asynchronous Future-based data |
| StreamProvider | Stream-based data |
| NotifierProvider | More structured application state and business logic |
Riverpod's documentation describes these provider types according to different state and dependency use cases.
final userProvider = FutureProvider((ref) async {
return fetchUser();
}); Riverpod's AsyncValue can represent loading, successful data, and error states for asynchronous operations.
Riverpod's StateProvider is intended for simple state that can be modified directly from the UI.
final selectedFilterProvider = StateProvider(
(ref) => 'all',
); Riverpod documentation recommends a more structured notifier approach when the state requires validation, is a complex object, or has more advanced modification logic.
NotifierProvider is useful when state requires centralized business logic rather than a simple direct value modification.
class CounterNotifier extends Notifier {
@override
int build() => 0;
void increment() {
state++;
}
} This approach is useful when the state has rules, multiple operations, validation, or more complex transitions.
FutureProvider is useful when application state comes from an asynchronous operation that returns a Future.
FutureProvider
↓
Async Operation
↓
Loading
↓
Success / Error
↓
UIStreamProvider is useful when application data changes continuously and is delivered through a Dart Stream.
final messagesProvider = StreamProvider>(
(ref) {
return messageStream();
},
); Bloc is useful when an application benefits from an explicit separation between events, business logic, and resulting states.
User Action
↓
Event
↓
Bloc
↓
Business Logic
↓
New State
↓
UICubit is a simpler approach from the Bloc ecosystem. Instead of requiring events for every interaction, methods can directly emit new states.
class CounterCubit extends Cubit {
CounterCubit() : super(0);
void increment() {
emit(state + 1);
}
} One of the most important decisions is determining whether the state belongs to the UI or represents business/application data.
This can often remain local.
This may benefit from a dedicated state management layer.
Keep state local when:
bool isPasswordVisible = false;There is usually little reason to make password visibility application-wide.
Consider shared state when:
Login Screen
↓
Authentication State
↓
Home Screen
↓
Profile Screen
↓
Settings ScreenFlutter's documentation notes that community state management packages can reduce boilerplate, provide specialized debugging tools, and support clearer or more consistent application architecture.
A package can become useful when:
A package may not be necessary when:
For example, a simple counter application does not need a large state architecture.
| Application Size | Possible Approach |
|---|---|
| Very Small | setState(), ValueNotifier |
| Small | setState(), lifted state, Provider |
| Medium | Provider, Riverpod, Bloc/Cubit |
| Large | Riverpod, Bloc/Cubit, Provider with strong architecture, or another structured solution |
This is a practical guideline rather than a strict rule. Application size alone does not determine the correct solution.
| State Complexity | Useful Approach |
|---|---|
| Single Boolean | setState() |
| Simple integer or string | setState() or ValueNotifier |
| Shared simple state | Provider or Riverpod |
| Async API state | Riverpod, Provider with appropriate architecture, Bloc/Cubit |
| Complex business state | Notifier-based architecture or Bloc/Cubit |
| Large feature state | Structured state management with clear architecture |
Asynchronous state is common in modern applications.
Initial
↓
Loading
↓
Successor
Loading
↓
ErrorWhen asynchronous state is common, choose an approach that makes loading, data, and error states easy to represent and test.
Simple business logic can often remain close to the widget.
Complex business logic should generally be separated from the UI.
void increment() {
setState(() {
count++;
});
}Load User
↓
Validate Session
↓
Fetch Profile
↓
Check Permissions
↓
Update Application State
↓
Display UIA dedicated state/controller layer can make such flows easier to understand and test.
If state and business logic need extensive automated tests, separating that logic from widgets can be useful.
Widget
↓
State Controller
↓
Repository
↓
API / DatabaseThe controller and repository can be tested without requiring the entire screen to be rendered.
The development team's experience is an important factor.
Flutter's simple app-state documentation uses Provider as an approachable starting point for developers who do not have a strong reason to choose another approach.
Sometimes the application needs to provide more than just state.
Examples include:
Provider and Riverpod can both be used in architectures where dependencies are exposed to the application. Riverpod places provider-based dependency management at the center of its design.
State changes can cause dependent widgets to rebuild. A useful approach should make it clear which widgets listen to which state.
App State
|
+-- Header
|
+-- Product List
|
+-- Cart
|
+-- FooterIf only the cart changes, the architecture should avoid unnecessarily rebuilding unrelated parts of the application whenever possible.
Ask whether the state needs to survive:
For example, a temporary animation value may disappear when its widget is removed, while a user preference may need persistent storage.
State management and persistent storage are related but are not the same thing. A state management solution can manage the in-memory representation of data, while a persistence mechanism can store data between sessions.
Real-time applications frequently receive data from streams.
A stream-oriented solution can be useful when the application continuously reacts to incoming data.
Consider a simple login screen.
bool isLoading = false;This may be managed locally.
User Login
↓
Authentication Service
↓
Authentication State
↓
Home ScreenOnce authentication needs to be shared across multiple screens, a dedicated application state solution may become useful.
A shopping cart usually needs to be accessed by several screens.
Product Screen
↓
Add Item
↓
Cart State
↙ ↘
Cart Checkout
Screen ScreenBecause the cart is shared across features, Provider, Riverpod, Bloc/Cubit, or another application-level approach can be useful.
Search can contain multiple kinds of state.
| State | Possible Approach |
|---|---|
| Search field text | Local state or simple provider |
| Selected filter | Local state or StateProvider |
| API results | Async state solution |
| Loading indicator | Local or feature state |
| Error message | Feature state |
This demonstrates that one feature can contain different types of state with different scopes.
Theme selection may affect the entire application.
Theme Preference
↓
Application State
↓
MaterialApp
↓
All ScreensBecause many widgets depend on the theme, application-level state management can be useful for custom theme preferences.
Animation progress is usually a visual concern of the widget performing the animation.
Animation Widget
↓
Animation Controller
↓
Animation Progress
↓
Widget RebuildThis is generally a good example of state that should remain local rather than becoming global application state.
A simple form can often use Flutter's built-in form and widget state mechanisms.
For example:
For a simple screen, local state may be sufficient. A complex multi-step form shared across screens may benefit from a dedicated state layer.
A Firebase application can contain multiple state categories.
| Firebase Feature | Potential State |
|---|---|
| Authentication | Logged-in user and authentication status |
| Firestore | Documents, collections, loading, errors |
| Storage | Upload progress and result |
| Messaging | Notification state |
A structured state solution can help keep Firebase operations separate from UI widgets.
You do not need to use one state management technique for every state in an application.
Application
│
├── Authentication → Riverpod / Provider / Bloc
├── Shopping Cart → Riverpod / Provider / Bloc
├── Products → Riverpod / Provider / Bloc
│
└── Product Details
├── Selected Image → setState()
├── Animation → local state
└── Quantity → local or feature stateA mix-and-match approach can be appropriate when each state has a different scope. Flutter's guidance explicitly recognizes that widget-owned state, parent-owned state, and mixed approaches are all valid depending on how the widget is expected to be used.
It is often better to understand the application's state requirements before selecting a package.
"Which state management package is the best?"
Does only one widget need the state?
|
Yes
↓
Use local state
or setState() No
↓
Do nearby widgets need the state?
|
Yes
↓
Lift state to parent
or use a simple notifier No
↓
Does multiple-screen or
application-wide state exist?
|
Yes
↓
Consider Provider,
Riverpod, Bloc/Cubit,
or another structured approach ↓
Is business logic complex?
|
Yes
↓
Separate state/business logic
from UI| Approach | Useful When | Complexity |
|---|---|---|
| setState() | Widget-specific state | Low |
| Lift State Up | Nearby widgets share state | Low |
| ValueNotifier | Small reactive values | Low |
| InheritedWidget | Low-level widget-tree data sharing | Medium |
| Provider | Shared state and dependency access | Low to Medium |
| Riverpod | Reactive, shared, async state and dependencies | Medium |
| StateProvider | Simple Riverpod state | Low to Medium |
| NotifierProvider | Complex Riverpod state and business logic | Medium |
| FutureProvider | Future-based asynchronous data | Medium |
| StreamProvider | Stream-based real-time data | Medium |
| Cubit | Structured state with direct state changes | Medium |
| Bloc | Explicit event and state architecture | Medium to High |
Not every piece of state needs to be application-wide.
Large business logic inside widgets can make code difficult to maintain.
A simple screen may not need a sophisticated state management architecture.
Popularity does not necessarily mean that a solution matches the requirements of a particular project.
A state management approach should be understandable and maintainable by the development team.
Using several unrelated state management patterns without clear boundaries can make an application difficult to understand.
Before making a state global, determine whether the state actually needs to be shared.
Use it primarily for simple widget-specific or ephemeral state.
When multiple related widgets need to access or modify the same state.
Provider is useful for sharing state and dependencies through the widget tree with less boilerplate than implementing inherited widgets manually.
Riverpod is useful for shared state, dependency management, asynchronous state, and applications that benefit from provider-based architecture.
Bloc can be useful when an application benefits from explicit event-to-state flows and structured business logic.
No. Different kinds of state can reasonably use different techniques when the boundaries are clear.
No. State should generally remain as local as practical.
Consider state scope, application complexity, asynchronous operations, business logic, testing, performance, architecture, and team experience.
| Question | Guideline |
|---|---|
| Only one widget needs state? | Consider setState() |
| Nearby widgets share state? | Lift state to a parent |
| Small reactive value? | Consider ValueNotifier |
| Shared state? | Consider Provider or Riverpod |
| Simple Riverpod value? | Consider StateProvider |
| Complex Riverpod business logic? | Consider NotifierProvider |
| Future-based data? | Consider FutureProvider or another async solution |
| Stream-based data? | Consider StreamProvider or another stream solution |
| Complex event/state flow? | Consider Bloc |
| Simpler structured state? | Consider Cubit |
After studying this topic, you should be able to:
For structured Flutter learning and practical development training, explore the following resources:
Different Flutter state management approaches are useful for different situations. setState() is suitable for simple widget-specific state, while lifting state can help when nearby widgets share data. ValueNotifier is useful for small reactive values, and InheritedWidget provides a lower-level mechanism for sharing information through the widget tree.
Provider can simplify shared state and dependency access, while Riverpod provides a provider-based approach with support for different types of synchronous and asynchronous state. Bloc and Cubit can provide more structured state flows for applications with complex business logic.
The most important skill is not memorizing one package. It is learning to identify who needs the state, how long the state should live, how complex the state is, how it changes, and how the application needs to test and maintain it. Once those requirements are clear, selecting an appropriate state management approach becomes much easier.
