With Flutter's provider package, how do ProxyProvider and ChangeNotifierProxyProvider build a value from other providers, and what goes wrong if update creates a new notifier?

## The problem proxies solve A provider's `create` runs once. If an object depends on another provider's value that can change — a cart total that depends on the cart, a checkout that needs the current total — `create` would capture the first value and never see later ones. The package's documentation spells this out and points to the **proxy providers**, whose `update` callback runs again when an input changes. ## `ProxyProvider`: derived values `ProxyProvider<T, R>` reads a `T` from an ancestor provider and exposes an `R`. Its callback has the signature `update(BuildContext context, T value, R? previous)`: - `update` is called when the value is **first read**, like `create` in other providers; - it is called again **whenever the proxy rebuilds or a provider it depends on updates**, because under the hood the proxy reads its inputs with a listening `Provider.of`; - `previous` is the last value returned, `null` the first time. The number after the class name is the number of inputs: `ProxyProvider2<Cart, PriceList, CartTotal>` receives both, up to `ProxyProvider6`. `ProxyProvider0` has no typed inputs and reads what it needs inside `update`. When `update` returns a value that is not `==` to the previous one, dependents rebuild; if a `dispose` callback was given, the previous value is disposed. For a **pure combination** of inputs — a total computed from quantities and prices — `ProxyProvider` with an immutable result is the recommended tool. ## `ChangeNotifierProxyProvider`: long-lived notifiers with inputs Sometimes the result has its own mutable state and methods, such as a `Checkout` notifier that tracks whether an order is being placed. `ChangeNotifierProxyProvider<T, R>` requires both callbacks: 1. `create` builds the notifier **once**; 2. `update(context, value, previous)` hands the new input to that existing notifier, typically through a setter or method, and returns it. It listens to the notifier like `ChangeNotifierProvider` and disposes it when leaving the tree. ## The mistake: re-creating in `update` The package lists this as a **don't**: returning `Checkout(total)` from `update`. | Behaviour | Reusing `previous` | Creating a new notifier in `update` | |---|---|---| | State such as `isPlacingOrder` | kept | lost on every input change | | Previous notifier | kept and still listened to | disposed, listener removed | | Subscription | unchanged | re-subscribed to the new object | | Dependents | rebuild only when the notifier notifies | rebuild because the value changed identity | In the source, when `update` returns a value that differs from the previous one, the provider removes its listener from the old value and calls the dispose callback on it, which for the ChangeNotifier variant is `dispose()`. A widget still holding the old notifier would then be calling a disposed object. ## Ordering and composition Proxy providers find their inputs by walking **up** the tree, so inputs must be listed **earlier** in a `MultiProvider`: ```dart MultiProvider( providers: [ Provider<PriceList>(create: (_) => const PriceList({'Baguette': 350})), ChangeNotifierProvider<Cart>(create: (_) => Cart()), ProxyProvider2<Cart, PriceList, CartTotal>( update: (_, cart, prices, _) => CartTotal.of(cart, prices), ), ], child: const BakeryApp(), ) ``` Chains are possible — a proxy can depend on another proxy — but each link recomputes when anything upstream changes, so long chains should stay cheap and their values should implement `==` to avoid needless rebuilds. ## Proxy or computed getter? Not every derived value needs its own provider. If only one widget needs the cart total, a getter on `Cart` — `int totalWith(PriceList prices)` — or a computation in that widget's `build` is simpler. A proxy earns its place when several widgets across the tree need the derived value, when it should be looked up by type like any other dependency, or when its `==` lets unrelated cart changes skip rebuilds of widgets that only show the total. The same reasoning applies in reverse: a proxy whose result nobody reads by type is indirection without benefit. ## Checklist - Immutable derived value: `ProxyProvider`, with `==` on the result. - Mutable object with its own state: `ChangeNotifierProxyProvider`, create once, mutate `previous` in `update`. - Inputs above the proxy, never below. - Keep `update` fast and free of network calls; start those from the notifier's methods.