How do you choose a state management approach?

State management is mostly about ownership and rebuild scope. Local UI state can stay in State. Shared state needs a single source of truth with clear lifecycle. Server state has caching, retries and invalidation concerns that differ from form state. Mixing those concerns in one global object is a common source of bugs.

• Ephemeral state: animation, focus, expansion and text input
• Screen or feature state: filters, selection and pagination
• App state: session, theme, locale and feature flags
• Server state: cached responses, request status and invalidation
• Derived state should be computed, not stored twice

class CartModel extends ChangeNotifier {
  final List<String> _items = [];

  List<String> get items => List.unmodifiable(_items);

  void add(String item) {
    _items.add(item);
    notifyListeners();
  }
}

class CartScope extends InheritedNotifier<CartModel> {
  const CartScope({
    super.key,
    required CartModel model,
    required Widget child,
  }) : super(notifier: model, child: child);
}

CartModel? readCart(BuildContext context) {
  return context.dependOnInheritedWidgetOfExactType<CartScope>()?.notifier;
}

Selection criteria

I weigh how much boilerplate the team tolerates, whether the state must survive navigation, how easy it is to test without widgets, and how granular rebuilds need to be. Provider is approachable for simple dependency injection. Riverpod improves composition and testability. Bloc gives explicit events and transitions that suit larger teams and audit-heavy flows.