What is BuildContext?

BuildContext is a handle to a widget's location in the tree — under the hood it is an Element. Two gotchas always trip people up: you need a context that is below the widget you're looking for, and after any await you must check context.mounted before using it again.

Flutter actually maintains three parallel trees:

BuildContext is the Element. That's why it knows where it is in the tree and can find ancestors.

---

What context lets you do

@override
Widget build(BuildContext context) {
  Theme.of(context);                   // climb up to nearest Theme
  MediaQuery.of(context);              // climb up to MediaQuery
  Navigator.of(context).pop();         // climb up to Navigator
  Scaffold.of(context).openDrawer();   // climb up to Scaffold

  context.size;                         // size of this element after layout
  context.findRenderObject();           // its RenderObject
  return ...;
}

Foo.of(context) is just sugar for "walk up the tree until you find a Foo (an InheritedWidget) and return it."

---

The "right context" gotcha

// ❌ Scaffold.of can't find a Scaffold — context is ABOVE it
@override
Widget build(BuildContext context) {
  return Scaffold(
    body: ElevatedButton(
      onPressed: () => Scaffold.of(context).openDrawer(),    // ⚠️ throws
      child: const Text('Open'),
    ),
  );
}

// ✅ Use Builder to get a context BELOW Scaffold
return Scaffold(
  body: Builder(
    builder: (innerCtx) => ElevatedButton(
      onPressed: () => Scaffold.of(innerCtx).openDrawer(),    // ✅ works
      child: const Text('Open'),
    ),
  ),
);

Rule: Foo.of(context) needs Foo somewhere above context in the tree.

---

The async gotcha — always check mounted

// ❌ Use after free — widget might be gone by now
Future<void> save(BuildContext context) async {
  await api.save(form);
  Navigator.of(context).pop();           // 💥 if user navigated away
}

// ✅ Guard with context.mounted
Future<void> save(BuildContext context) async {
  await api.save(form);
  if (!context.mounted) return;          // bail out cleanly
  Navigator.of(context).pop();
}

---

When to use which lookup

---

Common mistakes to avoid

// ❌ Saving context in a long-lived object
class Service { BuildContext? ctx; }            // ties Service lifetime to that screen

// ❌ Using context after the widget is disposed
Timer(const Duration(seconds: 3), () {
  Navigator.of(context).pop();                  // unsafe — user may have left
});

// ❌ Calling Foo.of(context) outside a build/lifecycle method without care
// of() registers a dependency — only meaningful inside the framework's call

// ❌ Heavy `MediaQuery.of(context)` everywhere — rebuilds on every metric change
// ✅ Prefer the targeted variants: MediaQuery.sizeOf(context), .paddingOf, etc.

// ❌ Using the wrong context layer for the lookup
// (the "Scaffold.of" trap above)

---

Interview follow-ups

1. Why are there three trees (Widget / Element / RenderObject)? Widgets are cheap, immutable descriptions — rebuilt freely. Elements persist and hold position + state references. RenderObjects do the expensive layout/paint work. Splitting them lets Flutter diff widgets without throwing away layout state.

2. What does .of(context) actually do? It walks up the Element tree to find the nearest matching InheritedWidget, and registers your element as a dependent — so when that inherited widget's data changes, your widget rebuilds.

3. Why do we need Builder or context.mounted checks? Builder provides a context below the widget you just declared (so Foo.of can find it). context.mounted (Flutter 3.7+) tells you whether the element is still in the tree after an async gap.

4. What's the cost of Theme.of(context) or MediaQuery.of(context)? Cheap lookup, but subscribes the calling widget to changes. Excessive MediaQuery.of causes rebuilds on irrelevant metric changes (keyboard, viewInsets). Use targeted helpers (MediaQuery.sizeOf, .paddingOf) to subscribe only to what you care about.

---