Learn Flutter - Advanced State Management

#Introduction

setState and Provider are enough for small apps, but as features grow — auth, shopping carts, synchronization, notifications — state management must be organized with discipline. Episode 10 compares the patterns most widely used by the community and helps you choose with reasons, not by following the crowd.

We discuss Provider, Riverpod, Bloc, GetX, and MobX, understand reactive state flow and dependency injection, explore modularization techniques for complex state, and build a framework for choosing an architecture based on app size and team.

#Patterns: Provider, Riverpod, Bloc, GetX, MobX

#Five Patterns at a Glance

• Provider: official from Google, simple, built on InheritedWidget. Great for getting started.
• Riverpod: Provider's evolution, compile-safe and testable without BuildContext.
• Bloc: event- and state-based, strict architecture, popular for large teams.
• GetX: all-in-one with routing and dependency injection, very concise.
• MobX: reactive, based on observables, similar to state management concepts in React.

flutter pub add flutter_riverpod

#Riverpod in a Glimpse

With Riverpod, state is defined as a provider separate from widgets:

final counterProvider = StateProvider<int>((ref) => 0);
 
class CounterScreen extends ConsumerWidget {
  const CounterScreen({super.key});
 
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider);
    return Text('Nilai: $count');
  }
}

StateProvider stores a simple value, and ref.watch(counterProvider) makes the widget react to its changes. ConsumerWidget replaces StatelessWidget for widgets that consume providers.

#Reactive State Flow and Dependency Injection

#One-Way Data Flow

All the patterns above follow the unidirectional data flow principle: state produces UI, interactions produce events, events change state, and the cycle repeats. The most common mistake is mutating state from anywhere without a clear path.

#Dependency Injection Through Provider

Provider isn't just for state — it's also for sharing objects like repositories or HTTP clients:

final postRepositoryProvider = Provider<PostRepository>((ref) {
  return PostRepository(httpClient: dio);
});

postRepositoryProvider builds PostRepository once and shares it across the whole app. This is dependency injection in its simplest form: widgets receive dependencies through providers instead of creating them themselves, so they can be easily overridden with mocks during testing.

#Managing Complex State and Modularization

#Split State per Feature

A medium app needs state separated by domain:

• AuthController — session and tokens.
• CartController — cart contents.
• OrderController — order status.

Don't lump all state into one giant object. Each feature has its own provider or controller, and screens consume only what they need.

class CartController extends ChangeNotifier {
  final List<Item> _items = [];
  int get totalBarang => _items.length;
 
  void tambah(Item item) {
    _items.add(item);
    notifyListeners();
  }
}

CartController manages a single responsibility. With this pattern, a change in one domain doesn't shake another — the key to maintainability.

#Mind the Rebuild Boundaries

The finer the provider granularity, the fewer widgets rebuild when state changes. The rule of thumb: listen at the smallest level. Don't watch a large state at the root if only one value is used — this is a cause of jank we'll discuss in episode 15.

#Choosing an Architecture Based on App Size

#A Decision Framework

Guidance for choosing a pattern:

• Prototypes and small apps: Provider or Riverpod — fast and sufficient.
• Large teams needing discipline: Bloc — explicit events and state.
• Developers who want maximum productivity: GetX — minimal boilerplate.
• Familiar with reactive ecosystems: MobX.

flutter pub deps --style=compact

flutter pub deps --style=compact shows the dependency tree as one line per package — practical for checking what's already in before adding a new pattern.

#Consistency Beats Dogma

The best architecture is the one the whole team understands. Whatever you choose, document the state flow in the README, use one pattern consistently, and don't mix three patterns in one project without a reason. Episode 20 will map this onto a production-scale architecture.

#Conclusion

Key takeaways:

• Provider to start; Riverpod, Bloc, GetX, and MobX as mature alternatives.
• All patterns follow unidirectional data flow.
• Use providers for dependency injection, not just state.
• Split state per domain: auth, cart, order each have their own controller.
• Listen to state at the smallest widget level to minimize rebuilds.
• Choose an architecture based on app size and team needs, then stay consistent.

In the next episode 11 we discuss navigation and app architecture — the difference between Navigator 1.0 and Navigator 2.0, named routes, nested routes, and deep linking, modular app architecture and feature modules, and code organization and separation of concerns. Your project structure starts moving to a real scale.