I like the orange color as another path to recover the sub-tree caches where available. Cache invalidation in arbitrary UI's is hard to get right for most case

I like the orange color as another path to recover the sub-tree caches where available. Cache invalidation in arbitrary UI's is hard to get right for most cases. SwiftUI manages state in a similar way, with automatic hashing and view-specific data-dependent updates. The annotated (@State, @Binding, @Environment, @Observable) data is the slice of interest, with other data expressly ignored. SwiftUI also gives the programmer some control, via explicitly changing the view id to trigger a refresh. Caching schemes are measured in the context of the kinds of use they get - for views, the runtime update model. The OO general-purpose procedural model of listening for changes proves both too heavyweight and too chaotic in its generality. It's faster to use flattened view-models with these cacheable slices, but these don't handle any real backend cross-component logic or batch updates, so you end up with threading driving UI. Often, logging updates shows a scary amount of duplicate renders. SwiftUI has already have a couple of direction changes and most developers consider it unfinished. Take that as a rough measure of complexity for the domain before getting too entangled :)