What state is, and setState

Two kinds of state

The Flutter docs divide state into two kinds. Ephemeral state (also called UI or local state) lives inside one widget and nobody else cares about it: the current tab of a TabBar, whether a password field shows its text, the progress of an animation. App state is shared across many parts of the app and often needs to survive moving between screens: the shopping cart, the logged-in user, notification settings, a list of favourites.

Lifting state up

When two sibling widgets need the same data, move the state to their closest common parent. The parent owns the data and passes it down as constructor arguments; children report changes upward through callbacks. This "lifting state up" keeps one source of truth.

class CartPage extends StatefulWidget {
  const CartPage({super.key});
  @override
  State<CartPage> createState() => _CartPageState();
}

class _CartPageState extends State<CartPage> {
  int _qty = 1;                                       // state lives in the parent

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        QuantityPicker(qty: _qty, onChanged: (q) => setState(() => _qty = q)),
        PriceSummary(total: _qty * 120),
      ],
    );
  }
}

class QuantityPicker extends StatelessWidget {
  const QuantityPicker({super.key, required this.qty, required this.onChanged});
  final int qty;
  final ValueChanged<int> onChanged;                  // callback up to the parent

  @override
  Widget build(BuildContext context) => Row(children: [
        IconButton(onPressed: qty > 1 ? () => onChanged(qty - 1) : null, icon: const Icon(Icons.remove)),
        Text('$qty'),
        IconButton(onPressed: () => onChanged(qty + 1), icon: const Icon(Icons.add)),
      ]);
}

The problem: prop drilling

Now imagine the cart count must appear in the AppBar of every screen, the checkout button, and a badge on the bottom navigation bar. Passing cart data and callbacks through every widget in between, even ones that do not use it, is called prop drilling. It makes code long, fragile and hard to change.

InheritedWidget: the foundation

Flutter solves this with InheritedWidget: a widget placed high in the tree that any descendant can read directly through BuildContext, without passing it down by hand. You already use it: Theme.of(context) and MediaQuery.of(context) read InheritedWidgets. Widgets that read it are rebuilt automatically when it changes. Writing InheritedWidgets by hand is verbose, so packages such as Provider wrap it in a friendlier API.

Common mistakes

• Putting all state in the top-level widget "just in case": every change rebuilds the whole app.
• Using a state management package for ephemeral state like a checkbox. setState is perfect there.
• Keeping two copies of the same data in different widgets, which get out of sync.
• Passing callbacks through five levels of widgets instead of using a shared state tool.