Provider package versus raw InheritedWidget

WHAT THIS TESTS Whether you know that Provider is built on top of InheritedWidget and understand the ergonomic and lifecycle problems it solves, rather than treating it as magic.

A GOOD ANSWER COVERS InheritedWidget is Flutter's primitive for propagating data down the tree so descendants can read it in O(1) and rebuild when it changes. Using it directly is verbose: you subclass it, write updateShouldNotify, write a static of method, and you must place it manually and dispose any resources yourself. Provider wraps all of this. It creates and exposes a value, handles disposal of ChangeNotifiers and streams, supports MultiProvider to compose many at once, and offers context.watch, context.read and context.select so widgets subscribe only to what they use.

COMMON WRONG ANSWERS Saying Provider has nothing to do with InheritedWidget, or that it is a global singleton store. Another error is claiming watch and read are interchangeable; watch subscribes and rebuilds, read does a one-off lookup with no subscription.

LIKELY FOLLOW-UPS Difference between Provider, ChangeNotifierProvider and FutureProvider. What does select do for performance. Why call read inside callbacks but watch inside build. How does disposal work.

ONE CONCRETE EXAMPLE A cart screen needs the item count and a checkout action. With raw InheritedWidget you would hand-write a CartInherited class, a notifier, and lookup plumbing. With Provider you wrap the subtree in ChangeNotifierProvider(create: ...), then a badge uses context.select to watch only items.length so it rebuilds when count changes, while the checkout button uses context.read inside onPressed to call a method without subscribing. The package eliminates the boilerplate and prevents leaks by disposing the notifier automatically.