Week 6: State Management I — setState, InheritedWidget & ValueNotifier

1. setState & Why It Doesn't Scale

setState does exactly one thing: it tells Flutter "this widget's state changed, rebuild it (and its descendants)." That's precisely calibrated for state that's genuinely local to one widget — but it has a hard structural limit.

class ProductListScreen extends StatefulWidget { /* ... */ }
class _ProductListScreenState extends State<ProductListScreen> {
  int _cartCount = 0; // lives here...

  void _addToCart() => setState(() => _cartCount++);

  // ...but the bottom nav bar (a sibling, not a descendant) also needs
  // _cartCount to show a badge. setState alone has no way to reach it —
  // there's no shared ancestor holding the state both widgets can see.
}

The moment two widgets that aren't in a direct parent-child relationship need the same piece of state, setState alone runs out of road — the state has to live somewhere both can reach, which means moving it up to a common ancestor and finding a way to get it back down without manually threading it through every layer in between ("prop drilling").

2. InheritedWidget

InheritedWidget is Flutter's built-in mechanism for making data available to any descendant, however deep, without passing it explicitly through every constructor along the way.

class CartCount extends InheritedWidget {
  final int count;
  const CartCount({super.key, required this.count, required super.child});

  static int of(BuildContext context) {
    final widget = context.dependOnInheritedWidgetOfExactType<CartCount>();
    return widget!.count;
  }

  @override
  bool updateShouldNotify(CartCount oldWidget) => count != oldWidget.count;
}

final count = CartCount.of(context); // works from any descendant, any depth

context.dependOnInheritedWidgetOfExactType is what makes this efficient — it registers the calling widget as a dependent, so only widgets that actually read CartCount rebuild when it changes, not the entire subtree underneath it.

3. ValueNotifier & ChangeNotifier

InheritedWidget solves getting data down the tree; it doesn't itself solve mutating that data cleanly. ValueNotifier and ChangeNotifier are the standard building blocks for observable, mutable state that pairs naturally with it.

final cartCount = ValueNotifier<int>(0);

// anywhere that needs to react to changes:
ValueListenableBuilder<int>(
  valueListenable: cartCount,
  builder: (context, count, child) => Badge(label: Text('$count')),
)

// mutating it — every listener rebuilds automatically
cartCount.value++;

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

  void add(String item) {
    _items.add(item);
    notifyListeners(); // tells every listener to rebuild
  }
}

This is the exact shape Provider and Riverpod are built on top of — ChangeNotifier plus a mechanism to make one instance reachable from anywhere in the tree (which is precisely what InheritedWidget provides) is, underneath the API sugar, what next week's libraries actually are.

4. Hands-on Exercise

5. Knowledge Check

Four quick questions. Expand each to check your answer.