In Flutter, how do you build an InheritedModel so a widget that reads only the unit system does not rebuild when the map style changes?

## The problem InheritedModel solves A plain `InheritedWidget` has one notify decision for all dependents. A hiking app's settings scope might hold the **unit system** (read by dozens of distance, elevation and pace labels) and the **map style** (read by the map and its legend). With a plain scope, switching the map style from topographic to satellite rebuilds every distance label, because `updateShouldNotify` can only say "something changed". **`InheritedModel<T>`** is an `InheritedWidget` whose dependents qualify their dependency with an **aspect** of type `T`. The model then decides per dependent. ## The pieces 1. **The aspect type.** Usually an enum, such as `enum TrailAspect { units, mapStyle }`. `MediaQuery` uses a private enum the same way. 2. **Registering accessors.** `InheritedModel.inheritFrom<M>(context, aspect: a)` finds the model and records `a` for the calling element. Wrap it in static methods so callers never pass raw aspects. 3. **`updateShouldNotify(oldWidget)`**, the coarse gate: return `true` if anything any dependent could read changed. 4. **`updateShouldNotifyDependent(oldWidget, dependencies)`**, the fine gate: `dependencies` is that dependent's `Set<T>` of aspects; return `true` only if a changed field corresponds to one of them. 5. **`isSupportedAspect(aspect)`**, optional, defaulting to `true`. ## What the element does The `InheritedModelElement` keeps, per dependent, either nothing, an empty set, or a set of aspects: | Registration | Stored as | Notified when | |---|---|---| | `inheritFrom(context)` with no aspect | empty set | `updateShouldNotify` is true | | `inheritFrom(context, aspect: units)` | `{units}` | gate true and dependent check true for `{units}` | | a no-aspect call plus an aspect call, in either order | an empty set | `updateShouldNotify` is true | Aspects **accumulate**: calling `unitsOf` and `mapStyleOf` from one build yields `{units, mapStyle}`. An unconditional registration is never narrowed afterwards; the element's dependencies are only reset when it is deactivated. That is why one stray no-aspect lookup undoes the optimisation for that element. Order of evaluation matters for correctness: if `updateShouldNotify` forgets a field, no dependent is checked at all, even if `updateShouldNotifyDependent` handles it perfectly. ## Walking through one change The app holds `units: metric` and `mapStyle: topo`. Forty distance labels called `unitsOf`, and the map and its legend called `mapStyleOf`. The user switches the map to satellite: 1. The settings `State` rebuilds `TrailSettingsModel` with `mapStyle: satellite`. 2. `updateShouldNotify` sees `mapStyle` differ and returns `true`. 3. For each distance label, `updateShouldNotifyDependent(old, {units})` checks `units`, finds it unchanged, and returns `false`; the label is left alone. 4. For the map and legend, the call with `{mapStyle}` returns `true`, so they get `didChangeDependencies` and rebuild. Two widgets rebuild instead of forty-two. Had one label also called a no-aspect accessor, it would have rebuilt too, because its set would be empty. ## Shadowing with `isSupportedAspect` When models of the same type are nested, `inheritFrom` starts at the nearest one. If that model's `isSupportedAspect(aspect)` returns `false`, the lookup registers on it **and** continues to the next ancestor model, stopping at the first that supports the aspect, whose data is returned. A trail-detail screen could override only `mapStyle` for its subtree while `units` still resolves to the app-wide model, and a dependent is still notified if the inner model later changes. ## When it is worth it - **Use it** when a scope holds parts that change independently, each read by many widgets, and profiling shows rebuilds of the wrong readers. - **Skip it** for a single value, for data that changes rarely, or when splitting into two separate `InheritedWidget`s is simpler; two scopes give the same isolation without aspect bookkeeping. - Remember the cost: every notification runs a per-dependent comparison, and a wrong comparison produces stale UI that is hard to spot. The framework's best-known use is `MediaQuery`, whose accessors such as `sizeOf` and `paddingOf` are exactly this pattern.