Question 1

How does Provider work under the hood? Where is the "magic"?

Accepted Answer

Start from the mechanism, not the package name. 1. Provider is a wrapper over InheritedWidget — that is the package's own description. 2. context.watch<T>() calls dependOnInheritedWidgetOfExactType internally: the element subscribes to the InheritedWidget. That lookup does not walk the tree — the element keeps a type-keyed map, so it is O(1). 3. When the value changes the InheritedWidget is rebuilt, updateShouldNotify returns true, and Flutter schedules the subscribed elements with markNeedsBuild. 4. ChangeNotifierProvider adds one layer on top: it listens to notifyListeners() and creates a new InheritedWidget. Close with: flutter_bloc uses the same mechanism — BlocProvider is built on package:provider. That supports the point that libraries differ in syntax and discipline, not in mechanism.

Question 2

What is the difference between InheritedWidget and InheritedModel, and what problem does it solve?

Accepted Answer

InheritedWidget notifies all-or-nothing: when updateShouldNotify returns true, every dependent rebuilds, including those reading a field that did not change. InheritedModel splits the subscription into keys called aspects. A dependent declares which aspect it depends on, the model reports which aspects changed, and only matching dependents wake. Draw the comparison: this is exactly the problem solved by Selector/context.select in Provider and provider.select in Riverpod. "Selective rebuild" is not a library invention — it is a wrapper over a need that exists at framework level.

Question 3

Why does context matter, and why is calling dependOnInheritedWidgetOfExactType in initState a problem?

Accepted Answer

context is a handle to an element in the tree; the lookup walks upward from that element. Two consequences follow: The wrong context — say the previous screen's context after a Navigator.push, or a context above the provider itself — produces a "provider not found" error. At initState time the element is mounted, but creating a dependency is not safe: the framework disallows subscribing at that point because a change notification could not yet be handled. Flutter offers didChangeDependencies for exactly this — subscribing reads belong there. The practical answer: in initState do only non-subscribing reads (read), and when you need to react to changes use didChangeDependencies or a listen-style API.

Question 4

When would you write your own InheritedWidget instead of using a library?

Accepted Answer

Name three concrete cases: You are writing a package or SDK — you don't want to impose a state management dependency on users. Rarely changing configuration — theme, locale, feature flags, a DI root. Here updateShouldNotify is a plain == and 20 lines is enough. Team context — in a small app, the cost of teaching a new library outweighs the benefit. Then show the boundary: once async loading, caching, error/loading state, parameterised scopes and disposal appear, the hand-rolled solution becomes a weak copy of a library — that is where I stop and move to Provider or Riverpod. This reads as more mature than either "always a library" or "always by hand".

Class	What it gives you	Typical use
`InheritedWidget`	O(1) lookup in the tree plus all-or-nothing notification via `updateShouldNotify`	Configuration that is immutable or changes rarely
`InheritedModel`	Notification split into aspects — a dependent only wakes for the part it cares about	Several independent values in one scope
`InheritedNotifier`	Wires a `Listenable` into the tree: when the notifier fires, dependents rebuild	A hand-rolled scope backed by a `ValueNotifier`/`ChangeNotifier`

InheritedWidget: the base of every library

📚 Sources and documentation