Choosing the right state management approach is an important part of building maintainable, scalable, and responsive Flutter applications. Flutter provides several built-in ways to manage state, while the Flutter ecosystem also offers packages such as Provider, Riverpod, and Bloc.
There is no single state management solution that is best for every application. The appropriate choice depends on the application's size, complexity, type of state, team experience, architecture, testing requirements, and long-term maintenance needs.
State management is the process of storing, updating, sharing, and reacting to application data so that the user interface always represents the current state of the application.
Examples of state include:
User Action
↓
State Changes
↓
State Management Layer
↓
UI Rebuilds
↓
Updated ScreenA small Flutter application can often manage state with setState(). As an application grows, however, state may need to be shared between multiple screens and separated from UI code.
A suitable state management approach can help with:
Before selecting a state management solution, identify the type and scope of the state.
Ephemeral state is usually temporary state that belongs to a particular widget or small section of the UI.
Examples:
This type of state can often be handled with StatefulWidget and setState().
Application state is state that needs to be accessed by multiple widgets, screens, or parts of an application.
Examples:
A useful principle is to avoid introducing a complex state management package before the application actually needs it.
If state belongs to one widget, setState() may be enough.
If several widgets need the same state, consider lifting the state to a common parent or using an appropriate shared-state solution.
As an application grows, state can be refactored into a more structured architecture.
setState() is Flutter's basic mechanism for updating widget-specific state.
class CounterPage extends StatefulWidget {
const CounterPage({super.key});
@override
State createState() => _CounterPageState();
}
class _CounterPageState extends State {
int counter = 0;
void increment() {
setState(() {
counter++;
});
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Counter'),
),
body: Center(
child: Text(
'$counter',
style: const TextStyle(fontSize: 32),
),
),
floatingActionButton: FloatingActionButton(
onPressed: increment,
child: const Icon(Icons.add),
),
);
}
} When two or more widgets need the same state, the state can be moved to a common parent.
Parent Widget
|
+-- Child A
|
+-- Child BThe parent owns the state and passes the required data or callbacks to its children.
class ParentWidget extends StatefulWidget {
const ParentWidget({super.key});
@override
State createState() => _ParentWidgetState();
}
class _ParentWidgetState extends State {
int count = 0;
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Count: $count'),
ElevatedButton(
onPressed: () {
setState(() {
count++;
});
},
child: const Text('Increment'),
),
],
);
}
} ValueNotifier is useful when a small value needs to notify listeners when it changes.
final ValueNotifier counter = ValueNotifier(0); ValueListenableBuilder(
valueListenable: counter,
builder: (context, value, child) {
return Text('Count: $value');
},
); It can be useful for small, focused pieces of reactive state without introducing a third-party package.
InheritedWidget is a Flutter mechanism for efficiently passing data down the widget tree.
It is a lower-level approach and can be useful for understanding how several state management solutions work internally.
However, manually building a complete application architecture around InheritedWidget can require more boilerplate than higher-level solutions.
Provider is a popular Flutter package that simplifies access to shared objects and state. It builds on Flutter's widget-tree mechanisms and is commonly used with ChangeNotifier.
ProviderChangeNotifierProviderConsumerSelectorMultiProvidercontext.read()context.watch()context.select()class CounterModel extends ChangeNotifier {
int count = 0;
void increment() {
count++;
notifyListeners();
}
}void main() {
runApp(
ChangeNotifierProvider(
create: (_) => CounterModel(),
child: const MyApp(),
),
);
}class CounterScreen extends StatelessWidget {
const CounterScreen({super.key});
@override
Widget build(BuildContext context) {
final counter = context.watch();
return Text(
'Count: ${counter.count}',
);
}
} Riverpod is a provider-based state management and dependency management solution for Dart and Flutter.
It provides mechanisms for declaring state and dependencies separately from the widget tree and includes support for synchronous and asynchronous state.
ProviderScopeProviderConsumerWidgetConsumerref.watch()ref.read()NotifierProviderFutureProviderStreamProviderAsyncValuefinal counterProvider = StateProvider((ref) => 0); void main() {
runApp(
const ProviderScope(
child: MyApp(),
),
);
}class CounterScreen extends ConsumerWidget {
const CounterScreen({super.key});
@override
Widget build(BuildContext context, WidgetRef ref) {
final count = ref.watch(counterProvider);
return Scaffold(
body: Center(
child: Text('Count: $count'),
),
floatingActionButton: FloatingActionButton(
onPressed: () {
ref.read(counterProvider.notifier).state++;
},
child: const Icon(Icons.add),
),
);
}
}setState()Bloc is a structured state management approach commonly used when applications require clear event and state flows.
Cubit provides a simpler API where methods can directly emit new states.
User Action
↓
Event or Cubit Method
↓
Business Logic
↓
New State
↓
UI Rebuildclass CounterCubit extends Cubit {
CounterCubit() : super(0);
void increment() {
emit(state + 1);
}
} | Approach | Best Suited For | Complexity | Third-Party Package |
|---|---|---|---|
| setState() | Local widget state | Low | No |
| ValueNotifier | Small reactive state | Low | No |
| InheritedWidget | Low-level shared state | Medium | No |
| Provider | Simple to medium shared application state | Low to Medium | Yes |
| Riverpod | Shared, reactive, asynchronous, and dependency-based state | Medium | Yes |
| Bloc/Cubit | Structured and complex application state | Medium to High | Yes |
Do you have state?
|
v
Is it used by one widget?
|
Yes
|
v
Use setState()
No
|
v
Is it shared by nearby widgets?
|
Yes
|
v
Lift state to parent
or use a simple notifier
No
|
v
Does the application require shared
application-level state?
|
Yes
|
v
Consider Provider, Riverpod,
Bloc/Cubit, or another solution
|
v
Is the application highly complex?
|
Yes
|
v
Choose an approach that provides
clear architecture, testability,
and predictable state flowFor a small application, starting with setState() may be appropriate when most state is local.
Example applications:
For a medium application, shared state may benefit from Provider or Riverpod.
Examples:
Large applications usually need clearly separated state, business logic, dependencies, repositories, and UI layers. Provider, Riverpod, Bloc/Cubit, or another structured solution can be considered depending on project requirements and team conventions.
| State Scope | Possible Approach |
|---|---|
| One widget | setState() |
| Small widget subtree | Parent state, ValueNotifier, InheritedWidget, Provider |
| Multiple screens | Provider, Riverpod, Bloc/Cubit |
| Application-wide state | Provider, Riverpod, Bloc/Cubit |
| Complex asynchronous state | Riverpod, Bloc/Cubit, or another structured solution |
The team's experience is an important factor when selecting a state management approach.
StatefulWidget and setState().If an application has very simple state, a simple approach is usually easier to maintain.
If business rules become complex, separating business logic from widgets becomes increasingly important.
bool isDarkMode = false;This can often be handled with simple state management.
Load Products
↓
Check Authentication
↓
Fetch API Data
↓
Apply Filters
↓
Apply Sorting
↓
Handle Pagination
↓
Handle Loading/Error/Success
↓
Update UIFor this type of flow, a structured state management solution can make the application easier to organize.
Applications that communicate with APIs or Firebase often need more than a single data value.
A useful state model can represent:
enum RequestStatus {
initial,
loading,
success,
error,
}Initial
↓
Loading
↓
Successor
Loading
↓
ErrorA common mistake is using several Boolean variables to represent one state.
bool isLoading = false;
bool hasError = false;
bool hasData = false;This can create invalid combinations such as loading and error both being true.
enum Status {
initial,
loading,
success,
error,
}A single state representation can make the application's state transitions easier to understand.
If your application frequently performs asynchronous operations, consider how the chosen solution represents loading, success, and error states.
Common asynchronous operations include:
Riverpod provides asynchronous provider patterns such as FutureProvider, StreamProvider, and AsyncValue. Other solutions provide their own ways of modeling asynchronous state.
State management becomes especially important when application logic needs automated testing.
A good architecture should allow business logic to be tested without requiring the entire UI.
UI
↓
ViewModel / State Controller
↓
Repository
↓
API / DatabaseThis separation allows the state layer and repository layer to be tested independently.
Flutter rebuilds widgets when their relevant state changes. A good state management solution should make it possible to control which widgets listen to which state.
For example:
Application State
|
+---- Header
|
+---- Product List
|
+---- Cart
|
+---- FooterIf only the cart changes, an efficient architecture should avoid rebuilding unrelated parts of the UI whenever possible.
Global state is not automatically better than local state.
For example, an animation controller generally does not need to become application-wide state.
A useful question is:
Who actually needs this state?
If only one widget needs it, keep it local. If several unrelated areas need it, consider shared state.
State management should work together with application architecture rather than becoming a replacement for architecture.
lib/
├── models/
├── views/
├── viewmodels/
├── repositories/
├── services/
├── providers/
└── main.dart| Layer | Responsibility |
|---|---|
| View | Displays UI and handles simple UI interactions |
| ViewModel / Controller | Manages UI state and application logic |
| Repository | Provides application data |
| Service | Communicates with external systems |
| Model | Represents application data |
A repository can act as the source of application data while the state management layer manages how that data is presented to the UI.
UI
↓
State Controller / ViewModel
↓
Repository
↓
API / Firebase / Local Databaseclass ProductRepository {
Future> getProducts() async {
// Fetch products from an API
return [];
}
} class ProductViewModel extends ChangeNotifier {
final ProductRepository repository;
ProductViewModel(this.repository);
bool isLoading = false;
List products = [];
Future loadProducts() async {
isLoading = true;
notifyListeners();
products = await repository.getProducts();
isLoading = false;
notifyListeners();
}
} | Factor | Provider | Riverpod |
|---|---|---|
| Learning Curve | Generally simple to start | More concepts to learn |
| Flutter Integration | Strong | Strong |
| Dependency Management | Supported | Core capability |
| Async State | Requires appropriate patterns | Dedicated provider patterns available |
| Testing | Supported | Strong provider override/testing capabilities |
| Small Projects | Suitable | Suitable |
| Larger Projects | Suitable with good architecture | Suitable with good architecture |
The choice should be based on project requirements and team preferences rather than selecting a package only because it is popular.
| Factor | Riverpod | Bloc/Cubit |
|---|---|---|
| Core Idea | Provider-based state and dependency management | Structured state transitions |
| Async State | Strong support | Strong support |
| Learning | Requires understanding providers and references | Requires understanding Cubits, events, and states |
| Architecture | Flexible | Highly structured |
| Best Fit | Reactive state and dependency-driven applications | Applications needing explicit state flows |
A popular package is not automatically the correct solution for every project.
Adding a large architecture for a simple counter can create unnecessary complexity.
As an application grows, putting all business logic inside widgets can make the code difficult to maintain.
Global state can make dependencies harder to understand and can increase coupling.
Using different state management packages for every screen can make an application difficult for a team to understand.
A state management architecture should make important business logic testable.
A theoretically powerful solution can still be difficult to maintain if the development team does not understand it.
Before choosing a state management approach, ask the following questions:
Imagine a shopping application with the following features:
Different state can have different scopes.
| Feature | Possible State Scope |
|---|---|
| Search text | Local or feature-level state |
| Product list | Shared application state |
| Cart | Shared application state |
| Authentication | Application-level state |
| Payment status | Feature/application state |
| Animation | Local widget state |
The application could combine local state with a structured state management solution rather than forcing every state into one global store.
A news application may have:
API-related state could be managed using a structured asynchronous state approach, while small UI states such as selected tabs can remain local.
A simple login form may not require a large state management package.
class LoginPage extends StatefulWidget {
const LoginPage({super.key});
@override
State createState() => _LoginPageState();
}
class _LoginPageState extends State {
bool isLoading = false;
Future login() async {
setState(() {
isLoading = true;
});
await Future.delayed(const Duration(seconds: 2));
setState(() {
isLoading = false;
});
}
@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: isLoading ? null : login,
child: Text(
isLoading ? 'Logging in...' : 'Login',
),
);
}
} For a simple screen, this can be sufficient. If authentication state must be shared across many screens, a dedicated application-level state solution may become useful.
You do not necessarily have to use one technique for every piece of state.
Application
│
├── Authentication → Riverpod / Provider / Bloc
├── Cart → Riverpod / Provider / Bloc
├── Products → Riverpod / Provider / Bloc
│
└── Product Details
├── Selected Image → setState()
├── Animation → local state
└── Quantity → local or shared stateThe important principle is to keep each state at an appropriate scope.
Firebase-based applications commonly need to manage asynchronous data and authentication state.
Examples include:
A structured state management approach can help keep Firebase logic outside the UI layer.
For API-driven applications, a typical flow is:
UI
↓
State Controller
↓
Repository
↓
API Service
↓
HTTP Request
↓
Response
↓
Repository
↓
State Controller
↓
UI UpdateThis structure keeps network communication separate from the presentation layer.
State management can affect application performance because state changes may trigger widget rebuilds.
Maintainable state management should make it easy to answer:
If these questions are difficult to answer, the architecture may need simplification or restructuring.
StatefulWidget.setState().ValueNotifier and InheritedWidget concepts.| Scenario | Possible Choice |
|---|---|
| Simple counter | setState() |
| Widget-specific UI state | setState() |
| Small reactive value | ValueNotifier |
| Shared state in a small/medium application | Provider |
| Dependency-driven application | Riverpod |
| Complex asynchronous state | Riverpod or Bloc/Cubit |
| Explicit event/state architecture | Bloc |
| Simpler Bloc-style architecture | Cubit |
| Highly local state | Keep it local |
These are practical starting points rather than strict rules. Flutter's documentation emphasizes that there is no universal rule for classifying or managing every kind of state.
Do not start with the question:
"Which state management package should I use?"
Start with:
"What state does my application have, who needs it, and how complex is its lifecycle?"
Then select the simplest approach that satisfies those requirements.
lib/
├── main.dart
├── models/
│ ├── user.dart
│ └── product.dart
├── views/
│ ├── login_screen.dart
│ ├── home_screen.dart
│ └── product_screen.dart
├── viewmodels/
│ ├── auth_viewmodel.dart
│ └── product_viewmodel.dart
├── repositories/
│ ├── auth_repository.dart
│ └── product_repository.dart
├── services/
│ ├── api_service.dart
│ └── firebase_service.dart
└── providers/
└── app_providers.dartThe exact folder structure can vary depending on the project and chosen architecture. The important goal is clear separation of responsibilities.
State management is the process of managing application data and ensuring that the UI reflects the current state.
It is commonly appropriate for local, widget-specific, ephemeral state.
Local state is generally limited to a widget or small widget subtree, while application state may need to be shared across multiple parts of an application.
Provider is a Flutter package that simplifies exposing and consuming values and objects through the widget tree.
Riverpod is a provider-based state and dependency management solution for Dart and Flutter.
Bloc is a structured state management pattern that commonly represents application behavior through events and states.
Cubit is a simpler Bloc-family approach in which methods can directly emit new states.
No. State should generally be kept as close as practical to the widgets or features that need it.
Consider application size, state scope, complexity, asynchronous operations, architecture, testing, performance requirements, and team experience.
| Concept | Key Point |
|---|---|
| setState() | Simple local widget state |
| ValueNotifier | Small reactive state |
| InheritedWidget | Low-level widget-tree state sharing |
| Provider | Simple and flexible shared state and dependency access |
| Riverpod | Provider-based state and dependency management |
| Bloc | Event/state-oriented architecture |
| Cubit | Simpler direct state emission |
| Local State | State required by a small part of the UI |
| App State | State shared across application features |
| Repository | Provides application data |
After studying this topic, you should be able to:
setState() for simple local state.Learn more about Flutter development and practical Flutter training through the following resources:
Choosing a state management approach in Flutter is not about finding one universally correct package. The right approach depends on the scope of state, application complexity, asynchronous requirements, architecture, performance needs, testing requirements, and team experience.
For simple local state, setState() may be sufficient. For shared state, solutions such as Provider, Riverpod, or Bloc/Cubit can provide additional structure. As applications become larger, separating UI, state logic, repositories, and services can improve maintainability.
The most important principle is to choose the simplest approach that solves the actual problem while keeping state predictable, testable, maintainable, and easy for the development team to understand.
