Difference between context.watch, context.read, and Selector in Provider and Riverpod

What's really being asked

This question tests your understanding of Flutter widget rebuild granularity and subscription semantics in the Provider family. Interviewers want to see that you know how to minimize unnecessary rebuilds and avoid anti-patterns like reading state reactively when you should be listening, or listening to entire objects when only a single field matters.

The full answer

First, context.watch subscribes the current widget to the provider and triggers a rebuild every time the provider notifies its listeners. Use it when the widget needs to react to state changes directly in the build method. Second, context.read performs a single non-subscribing lookup of the current value and should never be used inside build for values that drive UI, because it will not rebuild when the state changes; it is intended for event handlers, callbacks, and initState. Third, Selector is a widget and context.select is its extension-method equivalent that let you listen to a derived slice of state; they compare the selected value using equality and rebuild only when that slice changes, which prevents rebuilds when unrelated fields mutate. Fourth, performance hierarchy from most to least expensive for fine-grained updates is context.watch on a large object, then Selector with a stable selector, then context.select for inline selection; read has zero listen cost but risks stale UI if misused.

The mistakes people make

A major red flag is using context.read inside build to derive UI values. Another is claiming Selector is just syntax sugar with no performance benefit. Some candidates confuse context.read with context.watch and argue that both listen, or they suggest using Selector everywhere including one-off lookups, which adds unnecessary widget overhead. Failing to mention that Selector performs equality checks to filter rebuilds is also a weak signal.

What usually comes next

An interviewer might ask how to handle mutable collections inside a Selector, or when to use context.select versus the Selector widget. They may also ask about Riverpod specifics, such as how Riverpod select differs from Provider, or how to avoid excessive rebuilds when deriving multiple values from a single provider.

A concrete example

Imagine a CartModel with itemCount and totalPrice. A badge icon should use context.watch on itemCount or a Selector that selects itemCount, so it rebuilds only when the count changes. The checkout button onPressed should use context.read to call cartModel.checkout inside the callback, because it does not need to rebuild when the model changes. If a details screen only cares about whether totalPrice exceeds one hundred dollars, use Selector with a selector that returns totalPrice greater than one hundred so the screen rebuilds only when that boolean flips, not when item names or other fields change.