Hello, everyone. Today, I’m here to talk about StateManagement, a topic that many of us find complicated. Let’s get started.
You can read the full article here.
At first glance, your Flutter project may seem as innocent as a small “hello world” application. But as things grow and screens, API calls, user interactions, and data management come into play, state management can suddenly turn into a horror movie.
Incorrect state management:
- Slows down your application.
- Ruins the readability of your code.
- Makes teamwork difficult.
- And worst of all, makes debugging impossible in the future.
In this article, we will examine the 10 most common mistakes made when managing state in Flutter, with real code examples and solutions.
We will also discuss how you can spot these mistakes in advance and write more performant, sustainable code.
1. Putting All State in One Place
Mistake: Putting all of the application’s state into a single Provider, Bloc, or State class.
class AppState with ChangeNotifier {
String userName = '';
int cartItemCount = 0;
bool isDarkMode = false;
List<String> notifications = [];
void updateUserName(String name) {
userName = name;
notifyListeners();
}
void addNotification(String message) {
notifications.add(message);
notifyListeners();
}
}This structure seems innocent in small projects. However, as the project grows:
- Unnecessary rebuilds occur (even if only one field changes, all listeners are triggered).
- The code becomes more complex.
- Testing becomes more difficult.
Solution:
Modular state management → Separate state classes or Blocs for each feature.
class UserState with ChangeNotifier {
String userName = '';
void updateUserName(String name) {
userName = name;
notifyListeners();
}
}
class CartState with ChangeNotifier {
int itemCount = 0;
void addItem() {
itemCount++;
notifyListeners();
}
}2. Unnecessary Rebuilds
Error: Wrapping the entire screen with Consumer or BlocBuilder.
Consumer<CartState>(
builder: (context, cart, child) {
return Scaffold(
appBar: AppBar(title: Text('Cart (${cart.itemCount})')),
body: ProductList(),
);
},
);When itemCount changes, the entire screen is redrawn.
Solution:
Use Selectors or small widgets to rebuild only the necessary parts.
AppBar(
title: Selector<CartState, int>(
selector: (context, cart) => cart.itemCount,
builder: (context, count, child) => Text('Cart ($count)'),
),
)3. Mixing Local and Global State
Mistake: Keeping UI-specific data in global state.
Example: Modal open/closed state is kept globally.
class AppState with ChangeNotifier {
bool isModalOpen = false;
}Solution:
Keep screen-specific states in StatefulWidget or local provider.
class MyScreen extends StatefulWidget {
@override
State<MyScreen> createState() => _MyScreenState();
}
class _MyScreenState extends State<MyScreen> {
bool isModalOpen = false;
}4. Mixing Business Logic with UI
Error: API calls or data processing code directly within widgets.
ElevatedButton(
onPressed: () async {
final data = await fetchData();
setState(() {
result = data;
});
},
child: Text("Load"),
)Solution:
Move the business logic to the state management layer.
class DataState with ChangeNotifier {
String result = '';
Future<void> loadData() async {
result = await fetchData();
notifyListeners();
}
}5. Use of Non-Immutable State
Error: Directly modifying the state object.
state.user.name = 'John'; // FalseSolution:
Keep State immutable, use copyWith.
class User {
final String name;
User({required this.name});
User copyWith({String? name}) {
return User(name: name ?? this.name);
}
}6. dispose() and Memory Management Neglect
Error: Failure to dispose of Streams, Controllers, or Timers.
class MyNotifier with ChangeNotifier {
final controller = StreamController();
}Solution:
Add the dispose() method.
@override
void dispose() {
controller.close();
super.dispose();
}7. Overuse of notifyListeners() in Provider
Error: Triggering all listeners for a single change.
void updateCart() {
itemCount++;
notifyListeners();
}Solution:
Split the data into pieces or rebuild the target with context.select().
8. Managing Everything with a Single Event in Bloc
Mistake: Consolidating all operations into a single event.
class AppEvent {}Solution:
Define a separate event for each transaction.
class LoadUser extends AppEvent {}
class UpdateCart extends AppEvent {}9. Defining Unnecessary Reactive Variables in GetX
Error: Making even unchanging data .obs.
final appName = 'MyApp'.obs; // Not usefulSolution:
Make only the values that change and affect the UI reactive.
10. Wrong Library Selection
Error: Selecting a library because it is popular without analyzing the project requirements.
Solution:
- Small projects → Provider / Riverpod
- Medium projects → Riverpod / Bloc
- Large team projects → Bloc / Clean Architecture
Conclusions and Recommendations
- Plan state management correctly at the beginning of the project.
- Use a modular approach.
- Reduce unnecessary rebuilds.
- Prefer immutable data structures.
- Don’t ignore testability.
Resources
Thank you for reading this far.
If you liked this article, don’t forget to click the clap button. You can subscribe to stay updated on my other content.
Thank you.
Selin.
