Choosing the Right Approach

The State Management Landscape

Flutter offers many state management options, and choosing the wrong one can hurt your project. Too simple and you’ll outgrow it quickly; too complex and you’ll spend more time fighting the framework than building features. This lesson gives you a decision framework to pick the right approach for your specific situation.

The Options at a Glance

Here’s a comparison of the most popular approaches in the Flutter ecosystem as of Flutter 3.x:

┌──────────────────┬────────────┬────────────┬───────────┬────────────┐
│ Approach         │ Complexity │ Boilerplate│ Best For  │ Learning   │
│                  │            │            │           │ Curve      │
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ setState         │ Very Low   │ Minimal    │ Local UI  │ Beginner   │
│                  │            │            │ state     │            │
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ InheritedWidget  │ Medium     │ High       │ Learning  │ Intermediate│
│ / InheritedModel │            │            │ Flutter   │            │
│                  │            │            │ internals │            │
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ Provider         │ Low-Medium │ Low        │ Small to  │ Beginner-  │
│                  │            │            │ large apps│ Intermediate│
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ Riverpod         │ Medium     │ Low-Medium │ Medium to │ Intermediate│
│                  │            │            │ large apps│            │
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ Bloc / Cubit     │ Medium-High│ High       │ Large,    │ Intermediate│
│                  │            │            │ team apps │ -Advanced  │
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ GetX             │ Low        │ Very Low   │ Rapid     │ Beginner   │
│                  │            │            │ prototyping│           │
├──────────────────┼────────────┼────────────┼───────────┼────────────┤
│ Redux            │ High       │ Very High  │ Teams from│ Advanced   │
│                  │            │            │ React/web │            │
└──────────────────┴────────────┴────────────┴───────────┴────────────┘

Decision Framework

Ask yourself these questions in order. Each answer narrows down your options:

Q1: Is the state used by only ONE widget?
  YES --> Use setState. Done.
  NO  --> Continue to Q2.

Q2: Is the state shared by a few nearby widgets (parent-child)?
  YES --> Consider passing via constructor or using
          InheritedWidget / Provider at the subtree level.
  NO  --> Continue to Q3.

Q3: How large is your app / team?
  ┌─────────────────────────────────────────────────────┐
  │ Small app (1-2 devs, <20 screens):                  │
  │   --> Provider is almost always the right choice.   │
  │       Simple, well-documented, officially recommended│
  │                                                     │
  │ Medium app (2-5 devs, 20-50 screens):               │
  │   --> Provider or Riverpod.                         │
  │       Riverpod adds compile-time safety and better  │
  │       testability. Provider is simpler to learn.     │
  │                                                     │
  │ Large app (5+ devs, 50+ screens):                   │
  │   --> Bloc or Riverpod.                             │
  │       Bloc enforces strict patterns that help large │
  │       teams stay consistent. Riverpod is more       │
  │       flexible but requires team discipline.        │
  └─────────────────────────────────────────────────────┘

Q4: Do you need strict event traceability / time-travel debugging?
  YES --> Bloc (events are first-class, logged, replayable)
  NO  --> Provider or Riverpod are simpler.

Q5: Does your team have React/Redux experience?
  YES --> They may prefer Bloc (similar event-driven pattern)
          or Redux (familiar but verbose in Dart).
  NO  --> Avoid Redux. Provider or Riverpod are more Dart-native.

Deep Dive: When to Use Each

setState -- The Foundation

Use setState for truly local, ephemeral UI state. It’s not a “bad” approach -- it’s the right approach for the right situation.

// PERFECT for setState:
// - Animation toggle
// - Form field visibility
// - Bottom sheet open/close
// - Tab selection
// - Expandable section

class SearchBar extends StatefulWidget {
  @override
  State<SearchBar> createState() => _SearchBarState();
}

class _SearchBarState extends State<SearchBar> {
  bool _isExpanded = false;
  final _controller = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return AnimatedContainer(
      duration: const Duration(milliseconds: 300),
      width: _isExpanded ? 300 : 48,
      child: Row(
        children: [
          IconButton(
            icon: const Icon(Icons.search),
            onPressed: () => setState(() => _isExpanded = !_isExpanded),
          ),
          if (_isExpanded)
            Expanded(
              child: TextField(controller: _controller),
            ),
        ],
      ),
    );
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
}

// WRONG for setState:
// - User authentication state (needed across app)
// - Shopping cart (shared across screens)
// - Theme preference (affects entire app)
// - API data that multiple widgets display

Provider -- The Sweet Spot

Provider is the officially recommended solution by the Flutter team. It wraps InheritedWidget in a clean, easy-to-use API. It scales from small apps to large ones and has excellent documentation.

Riverpod -- Provider’s Evolution

Created by the same author as Provider, Riverpod fixes Provider’s limitations: compile-time safety (no runtime ProviderNotFoundException), no BuildContext dependency for reading state, better testing, and provider autodispose.

// PROVIDER: Depends on BuildContext, runtime errors possible
class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Throws at RUNTIME if AuthNotifier isn't provided above
    final auth = context.watch<AuthNotifier>();
    return Text(auth.state.user?.name ?? 'Guest');
  }
}

// RIVERPOD: No BuildContext needed, compile-time safe
final authProvider = ChangeNotifierProvider((ref) => AuthNotifier());

class MyWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Compile-time safe -- authProvider is a global declaration
    final auth = ref.watch(authProvider);
    return Text(auth.state.user?.name ?? 'Guest');
  }
}

// RIVERPOD: Can read providers without BuildContext (great for testing)
void main() {
  final container = ProviderContainer();
  final auth = container.read(authProvider);
  // No widget tree needed!
}

Bloc -- Enterprise-Grade Structure

Bloc (Business Logic Component) enforces a strict pattern: Events go in, States come out. Every state change is traceable to a specific event. This is powerful for large teams because it eliminates ambiguity about how state changes happen.

// Bloc requires explicit events -- more code, more traceability
// Every state change maps to exactly one event

// Events -- what CAN happen
abstract class TodoEvent {}
class AddTodo extends TodoEvent {
  final String title;
  AddTodo(this.title);
}
class ToggleTodo extends TodoEvent {
  final String id;
  ToggleTodo(this.id);
}
class DeleteTodo extends TodoEvent {
  final String id;
  DeleteTodo(this.id);
}

// States -- what the UI shows
class TodoState {
  final List<Todo> todos;
  final bool isLoading;
  const TodoState({this.todos = const [], this.isLoading = false});
}

// Bloc -- maps events to state changes
class TodoBloc extends Bloc<TodoEvent, TodoState> {
  TodoBloc() : super(const TodoState()) {
    on<AddTodo>((event, emit) {
      emit(TodoState(
        todos: [...state.todos, Todo(title: event.title)],
      ));
    });

    on<ToggleTodo>((event, emit) {
      emit(TodoState(
        todos: state.todos.map((t) =>
          t.id == event.id ? t.copyWith(isCompleted: !t.isCompleted) : t
        ).toList(),
      ));
    });
  }
}

// Usage in widget
BlocBuilder<TodoBloc, TodoState>(
  builder: (context, state) {
    return ListView(
      children: state.todos.map((t) => TodoTile(todo: t)).toList(),
    );
  },
)

// Dispatching events
context.read<TodoBloc>().add(AddTodo('Buy milk'));
context.read<TodoBloc>().add(ToggleTodo('abc123'));

Migration Paths

You don’t have to commit to one solution forever. Here are common migration paths:

When Simple Is Better

Resist the urge to use the most “advanced” solution. Complexity has a real cost: more bugs, slower onboarding, harder debugging. Here are signs you’re over-engineering:

Practical Examples

// Perfect for Provider:
// - 5-10 screens
// - 1-2 developers
// - Simple CRUD operations
// - No complex async workflows

// main.dart -- simple setup
void main() {
  runApp(
    ChangeNotifierProvider(
      create: (_) => TodoNotifier(),
      child: const TodoApp(),
    ),
  );
}

// One file for all todo logic -- simple and clear
class TodoNotifier extends ChangeNotifier {
  final List<Todo> _todos = [];

  List<Todo> get todos => List.unmodifiable(_todos);

  void add(String title) {
    _todos.add(Todo(title: title));
    notifyListeners();
  }

  void toggle(int index) {
    _todos[index] = _todos[index].copyWith(
      isCompleted: !_todos[index].isCompleted,
    );
    notifyListeners();
  }

  void remove(int index) {
    _todos.removeAt(index);
    notifyListeners();
  }
}

// Good for Provider with proper structure:
// - 20-40 screens
// - 2-4 developers
// - Multiple shared state areas (auth, cart, products)
// - Some async workflows

// Organized with multiple providers
void main() {
  runApp(
    MultiProvider(
      providers: [
        ChangeNotifierProvider(create: (_) => AuthNotifier(AuthRepository())),
        ChangeNotifierProvider(create: (_) => CartNotifier()),
        ChangeNotifierProvider(create: (_) => ProductNotifier(ProductRepository())),
        ChangeNotifierProvider(create: (_) => ThemeNotifier()),
      ],
      child: const ShopApp(),
    ),
  );
}

// Each notifier handles one domain
// Keep them focused and independent

// Bloc shines for:
// - 50+ screens
// - 5+ developers
// - Complex async workflows (transactions, real-time data)
// - Strict audit/traceability requirements
// - Need to replay or log every state change

// Every action is a typed, trackable event
class TransferBloc extends Bloc<TransferEvent, TransferState> {
  final TransferRepository _repo;
  final AuditLogger _logger;

  TransferBloc(this._repo, this._logger)
      : super(TransferInitial()) {

    on<TransferInitiated>((event, emit) async {
      _logger.log('Transfer initiated: \${event.amount} to \${event.recipient}');
      emit(TransferProcessing());

      try {
        final result = await _repo.transfer(
          amount: event.amount,
          to: event.recipient,
        );
        _logger.log('Transfer completed: \${result.transactionId}');
        emit(TransferSuccess(result));
      } catch (e) {
        _logger.log('Transfer failed: \$e');
        emit(TransferFailure(e.toString()));
      }
    });
  }
}

// Full traceability -- you know exactly what happened and when
// BlocObserver logs every event and state transition globally

Summary