SAMPLE: Flutter State Management — setState vs Provider vs Riverpod

State is any data that can change while your app runs. Flutter rebuilds widgets when state changes, so where you keep state decides how much of the tree rebuilds.

1. setState: local, simple#

Use setState for state that belongs to a single widget, like a toggle or a text field.

class Counter extends StatefulWidget {
  const Counter({super.key});

  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    return TextButton(
      onPressed: () => setState(() => _count++),
      child: Text('Tapped $_count times'),
    );
  }
}

2. Provider: shared, familiar#

Provider wraps InheritedWidget so you can share a ChangeNotifier down the tree.

class CartModel extends ChangeNotifier {
  final List<String> _items = [];
  List<String> get items => List.unmodifiable(_items);

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

3. Riverpod: compile-safe, testable#

Riverpod providers are global declarations that do not depend on BuildContext, which makes testing easier.

final counterProvider = StateProvider<int>((ref) => 0);

Which one should you pick?#

• Start with setState; lift state up only when two widgets need it.
• Prefer immutable state objects; they make rebuilds predictable.