State management is one of the most important concepts in Flutter development. As applications become larger, managing data, user interactions, API responses, authentication, forms, themes, shopping carts, and other changing information becomes more complex.
Modern state management provides structured techniques for storing, updating, sharing, and reacting to application state. Flutter supports several approaches, ranging from simple local state with setState() to scalable solutions such as Provider, Riverpod, Bloc, and other state-management architectures.
State is the data or information that can change while an application is running and can affect what the user sees or how the application behaves.
Examples of state include:
int counter = 0;If the value changes from 0 to 1, the UI may need to display the new value. This changing information is application state.
State management is the process of storing, updating, sharing, and reacting to application state in a controlled way.
In a Flutter application, state management helps answer questions such as:
A small application can often manage state directly inside widgets. However, as the application grows, state can become difficult to maintain if it is scattered throughout the widget tree.
For example, an e-commerce application may need to manage:
User Authentication
↓
User Profile
↓
Products
↓
Product Details
↓
Shopping Cart
↓
Orders
↓
Payment StatusModern state management helps organize these responsibilities and makes the application's data flow easier to understand.
Flutter uses a declarative UI approach. Instead of manually telling every widget how to change, the developer describes what the UI should look like for the current state.
Current State
↓
Build UI
↓
User Interaction
↓
State Changes
↓
UI Rebuilds
↓
New State is DisplayedFor example, if a counter state changes from 0 to 1, the widget displaying the counter can rebuild and show 1.
A useful way to understand Flutter state management is:
UI = f(State)This means the UI is determined by the current state.
For example:
state = 0
UI → "0"
state = 1
UI → "1"
state = 2
UI → "2"When the state changes, Flutter can rebuild the relevant portion of the UI.
State can be classified in different ways depending on how widely it is used and how long it needs to exist.
Ephemeral state is usually local to a single widget or small part of the UI.
Examples:
setState() is often sufficient for this type of state.
Shared state is data that multiple widgets or screens need to access.
Examples:
Server state is data obtained from remote services or APIs.
Examples:
Persistent state is data that should remain available after an application is restarted.
Examples:
| Local State | Shared/Application State |
|---|---|
| Used by a small widget or screen. | Used by multiple parts of the application. |
| Usually has a small scope. | Usually has a wider scope. |
| Often managed with setState(). | Often managed with Provider, Riverpod, Bloc, or another architecture. |
| Simple to understand. | Requires more structured organization. |
| Example: selected checkbox. | Example: authenticated user. |
setState() is Flutter's built-in approach for managing local mutable state in a StatefulWidget.
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(
body: Center(
child: Text('$counter'),
),
floatingActionButton: FloatingActionButton(
onPressed: increment,
child: const Icon(Icons.add),
),
);
}
} This approach is simple and appropriate when state belongs to one widget.
setState() becomes less convenient when state needs to be shared across many unrelated widgets.
For example:
Screen A
↓
Screen B
↓
Screen C
↓
Screen DIf all these screens need the same state, manually passing the state through constructors can become difficult.
Common problems include:
Prop drilling occurs when data needs to be passed through multiple widgets even though intermediate widgets do not actually use that data.
Parent
↓ user
Child
↓ user
GrandChild
↓ user
DeepChildFor large applications, a dedicated state-management solution can reduce this problem.
Modern state management refers to structured approaches that separate application state from UI presentation and provide predictable ways to update and consume that state.
Modern solutions commonly provide:
Flutter developers can choose from several state-management approaches.
| Approach | Typical Use |
|---|---|
| setState() | Simple local widget state. |
| InheritedWidget | Sharing data through the widget tree. |
| Provider | Dependency injection and application state. |
| Riverpod | State management and dependency management. |
| Bloc/Cubit | Structured event/state-based application logic. |
| ValueNotifier | Simple reactive values. |
| ChangeNotifier | Mutable observable state. |
| GetX | State management and application utilities. |
| Other solutions | Different architectures may be selected according to project requirements. |
There is no single state-management solution that is correct for every application. The appropriate choice depends on project size, team experience, architecture, testing requirements, and the type of state being managed.
Provider is a popular Flutter package that simplifies exposing and consuming dependencies and state through the widget tree.
A basic Provider example:
final messageProvider = Provider(
(context) => 'Hello Flutter',
);Provider can be combined with ChangeNotifier to create reactive application state.
ChangeNotifier is a Flutter class that can notify listeners when its state changes.
class CounterModel extends ChangeNotifier {
int count = 0;
void increment() {
count++;
notifyListeners();
}
}When notifyListeners() is called, widgets listening to the notifier can rebuild.
Riverpod is a modern state-management and dependency-management solution for Dart and Flutter.
Riverpod uses providers to expose state and dependencies.
final counterProvider =
NotifierProvider(
CounterNotifier.new,
);Riverpod commonly uses APIs such as:
ProviderScopeConsumerWidgetref.watch()ref.read()NotifierProviderAsyncNotifierProviderFutureProviderStreamProviderBloc is an architecture and library ecosystem based around predictable state transitions. Cubit is a simpler approach from the same ecosystem where methods can directly emit new states.
class CounterCubit extends Cubit {
CounterCubit() : super(0);
void increment() {
emit(state + 1);
}
} The basic concept is:
Event or Method
↓
Business Logic
↓
New State
↓
UIValueNotifier is useful for simple reactive values.
final counter = ValueNotifier(0);
counter.value++;
counter.dispose();It can be connected to the UI using ValueListenableBuilder.
ValueListenableBuilder(
valueListenable: counter,
builder: (context, value, child) {
return Text('$value');
},
)InheritedWidget is a fundamental Flutter mechanism for efficiently propagating information down the widget tree.
Many state-management packages use Flutter's underlying widget-tree mechanisms or provide higher-level abstractions around them.
Understanding InheritedWidget helps developers understand how data can be shared through Flutter's widget hierarchy.
Modern state-management solutions are commonly reactive.
Reactive state management means that UI components listen to state and respond when that state changes.
State
↓
Change
↓
Notification
↓
Listening UI
↓
RebuildThis avoids manually updating every widget whenever data changes.
Many modern state-management architectures encourage unidirectional data flow.
User Action
↓
State Logic
↓
New State
↓
UI
↓
User ActionFor example:
Tap "Add to Cart"
↓
Cart Logic
↓
Cart State Updated
↓
Cart UI RebuildsThis makes the application's behavior easier to trace.
One important goal of modern state management is to keep business logic outside the UI wherever practical.
Widget
├── API call
├── validation
├── database logic
├── business logic
└── UIUI
↓
State Management
↓
Business Logic
↓
Repository
↓
Service
↓
API / DatabaseThis separation improves maintainability and testing.
Modern Flutter applications often separate responsibilities into different layers.
Presentation Layer
↓
State / ViewModel Layer
↓
Repository Layer
↓
Service / Data Layer
↓
API / Database / FirebaseState-management tools can be placed between the UI and the application's data and business logic layers.
Asynchronous operations need a way to represent loading.
enum Status {
idle,
loading,
success,
error,
}A UI can respond to the status:
if (status == Status.loading) {
return const CircularProgressIndicator();
}When an operation completes successfully, the state should contain the required data.
class AppState {
final Status status;
final List products;
const AppState({
required this.status,
required this.products,
});
}Error state allows the UI to display meaningful feedback when an operation fails.
if (status == Status.error) {
return const Text(
'Unable to load products',
);
}Modern state-management approaches often provide better patterns for representing loading, success, and error states than scattered boolean variables.
A common beginner pattern is:
bool isLoading = false;
bool hasError = false;
bool hasData = false;This can create invalid combinations such as loading and error being true simultaneously.
A single state representation can make the possible states clearer:
enum Status {
idle,
loading,
success,
error,
}Complex applications can use dedicated state classes.
class ProductState {
final bool loading;
final List products;
final String? error;
const ProductState({
this.loading = false,
this.products = const [],
this.error,
});
}This approach can keep related state values together.
Modern state-management architectures often favor immutable state. Instead of modifying an existing state object, a new state is created.
state.items.add(product);state = [
...state,
product,
];Immutable state can make state changes easier to understand, test, and track.
A state transition occurs when the application moves from one state to another.
Initial
↓
Loading
↓
SuccessOr:
Initial
↓
Loading
↓
ErrorThinking in terms of state transitions helps developers design predictable application behavior.
Some state-management architectures use events or actions to describe what happened.
User taps Login
↓
LoginRequested
↓
Authentication Logic
↓
LoginSuccess / LoginFailure
↓
UI UpdatesThis approach can be useful for large applications with complex business rules.
Notifier-based approaches place state-changing methods inside a dedicated notifier.
class CounterNotifier extends Notifier {
@override
int build() {
return 0;
}
void increment() {
state++;
}
} The UI interacts with the notifier rather than implementing the business logic itself.
Modern state-management solutions often support dependency injection. Dependency injection means providing the dependencies required by a class instead of having the class construct all dependencies itself.
API Service
↓
Repository
↓
ViewModel / Notifier
↓
UIThis makes components easier to replace and test.
The repository pattern separates application logic from data sources.
class ProductRepository {
Future getProducts() async {
// API or database logic
return [];
}
}
A state-management layer can then use the repository.
UI
↓
ProductNotifier
↓
ProductRepository
↓
APIAPI-driven applications usually require several states:
Modern state management provides a structured place to represent these conditions.
App Starts
↓
Initial
↓
API Request
↓
Loading
↓
Success ─────→ Display Data
│
└──────→ Empty → Display Empty UI
API Failure
↓
Error
↓
Display Retry UIFirebase applications can use state management for authentication, Firestore data, Storage operations, and other asynchronous operations.
Firebase
↓
Repository / Service
↓
State Management
↓
Flutter UIFor example, authentication state can be represented as:
Logged Out
↓
Login Requested
↓
Loading
↓
Logged InA typical authentication state may contain:
class AuthState {
final bool isAuthenticated;
final String? userId;
final String? error;
const AuthState({
required this.isAuthenticated,
this.userId,
this.error,
});
}The UI can use this state to determine whether to display the login page or application content.
A shopping cart is a common example of shared application state.
class CartState {
final List items;
const CartState({
this.items = const [],
});
int get itemCount => items.length;
}Multiple screens may need access to this state:
Product Page
↓
Add Product
↓
Cart State
↓
Cart Page
↓
Checkout PageTheme state is another example of shared application state.
enum AppTheme {
light,
dark,
}The application can use this state to control the theme.
MaterialApp(
themeMode: ThemeMode.light,
)A state-management solution can store and update the user's theme preference.
Forms can contain multiple state values such as:
Simple forms can use TextEditingController and setState(), while complex multi-screen forms may benefit from a dedicated state-management solution.
Search functionality can involve several state values:
Search Query
↓
Loading
↓
Results
↓
Empty / ErrorModern state management can keep the search query and results synchronized.
Applications that load data page by page need to track pagination state.
Page 1
↓
Load More
↓
Page 2
↓
Load More
↓
Page 3State may include:
Refreshing is different from the initial loading state in many applications.
Existing Data
↓
Refresh Requested
↓
Refreshing
↓
Updated DataA well-designed state model can preserve existing data while indicating that a refresh is occurring.
Modern state management should avoid rebuilding more widgets than necessary.
For example:
App
├── Header
├── ProductList
└── FooterIf only the product list changes, there may be no reason for unrelated widgets to rebuild.
Many state-management solutions provide mechanisms such as selectors, consumers, or granular listeners to optimize rebuilds.
Not every piece of state needs to be global.
A useful principle is:
Use the smallest scope that makes sense.For example:
A common mistake is putting every variable into a global state-management solution.
For example, this does not necessarily need global state:
bool isPasswordVisible = false;If only one login widget uses it, local state may be simpler.
setState() is often suitable when:
A dedicated solution can become useful when:
| Feature | Provider | Riverpod | Bloc/Cubit |
|---|---|---|---|
| Learning Curve | Relatively simple. | Moderate. | Moderate to advanced. |
| Local State | Possible. | Possible. | Possible. |
| Dependency Injection | Yes. | Yes. | Yes, often with supporting patterns. |
| Async State | Possible. | Strong support. | Strong support. |
| Business Logic Separation | Possible. | Strong support. | Strong support. |
| Testing | Supported. | Strong provider/container-based testing patterns. | Strong testing ecosystem. |
| Architecture | Flexible. | Flexible and composable. | Structured event/state architecture. |
The table describes common characteristics rather than ranking the solutions. The appropriate choice depends on application requirements and team preferences.
Consider the following questions before selecting a solution:
Flutter UI
↓
State Consumer
↓
State Controller / Notifier / Cubit
↓
Business Logic
↓
Repository
↓
Service
↓
API / Firebase / DatabaseThis architecture separates presentation, state management, business logic, and data access.
Consider a product application with the following requirements:
Possible state structure:
Product State
├── loading
├── products
├── error
└── searchQuery
Cart State
├── items
└── itemCountUser opens screen
↓
Product state requests data
↓
Repository calls API
↓
API returns response
↓
State is updated
↓
UI rebuilds
↓
User selects product
↓
Cart state changes
↓
Cart widgets rebuildOne of the main advantages of separating state logic from UI is that the logic can be tested independently.
For example, a counter controller can be tested without rendering the complete application.
Initial State → 0
Increment → 1
Increment → 2
Reset → 0This is easier to verify than testing every state transition through UI interaction.
A state-management unit test typically verifies:
Good state management improves maintainability by giving each part of the application a clear responsibility.
Widget
→ Displays UI
State Controller
→ Manages state
Repository
→ Coordinates data
Service
→ Communicates with external system
Model
→ Represents dataScalable state management allows a project to grow without placing all logic inside a small number of widgets.
A scalable structure might look like:
lib/
├── core/
├── models/
├── repositories/
├── services/
├── state/
├── screens/
├── widgets/
└── main.dartsetState().Create a task-management application using modern state management.
TaskScreen
↓
Task State Controller
↓
Task Repository
↓
Local StorageA more advanced practice project can contain:
This project provides practical experience with multiple types of application state.
State management is the process of storing, updating, sharing, and reacting to application data that can change over time.
Local state is generally used by one widget or small part of the UI, while shared state is required by multiple components or screens.
setState() is Flutter's built-in mechanism for notifying Flutter that the state of a StatefulWidget has changed and its UI may need to rebuild.
Provider is a package that simplifies dependency injection and state sharing through the Flutter widget tree.
Riverpod is a state-management and dependency-management solution based around providers.
Bloc is a structured state-management approach based around events, business logic, and state transitions.
Immutable state makes state transitions explicit and can make application behavior easier to reason about and test.
It is an architecture where user actions flow into state logic, state logic produces new state, and the UI reacts to that state.
No. Simple applications and local widget state can often be handled with Flutter's built-in mechanisms. A dedicated solution becomes useful when state sharing or application complexity increases.
They should be represented explicitly in the application's state model so the UI can render appropriate loading, success, empty, and error views.
| Concept | Meaning |
|---|---|
| State | Data that can change and affect application behavior or UI. |
| State Management | Managing, updating, sharing, and reacting to state. |
| setState() | Built-in approach for local StatefulWidget state. |
| Provider | State and dependency management through the widget tree. |
| Riverpod | Provider-based state and dependency management. |
| Bloc | Structured event/state-based state management. |
| ChangeNotifier | Observable mutable state that can notify listeners. |
| Notifier | Dedicated object for managing state and state-changing methods. |
| Reactive State | UI reacts automatically to relevant state changes. |
| Immutable State | State is replaced rather than directly mutated. |
| Repository | Layer responsible for coordinating data access. |
| Dependency Injection | Providing dependencies instead of constructing them inside consumers. |
After completing this topic, you should be able to:
Flutter State Management Documentation
Flutter Ephemeral and App State Documentation
Riverpod Official Documentation
Learn more about Flutter development through the JustAcademy Flutter training program:
JustAcademy Flutter Training Course
Register for Flutter Course Demo
Modern state management is an important part of building scalable Flutter applications. Small and local state can often be handled with setState(), while larger applications may benefit from solutions such as Provider, Riverpod, Bloc, or other structured approaches.
The main goal is not simply to use a state-management package. The goal is to create a predictable data flow, keep state ownership clear, separate UI from business logic, handle asynchronous states correctly, minimize unnecessary rebuilds, and make application logic easier to test and maintain.
A good Flutter developer should understand both simple built-in state management and modern scalable approaches, then select the appropriate technique according to the application's requirements.
