[Pitch] Observation (Revised)

[tcldr]

@Daniel_Steinberg

I often broke the pipelines into smaller pieces and various structs would subscribe to upstream publishers and modify or join them before republishing them. In this way we could create small pieces that did one thing that could be appropriately named and flexibly assembled. I was thinking we could do the same with @Observables upstream that we might assemble with things from async algorithms etc.

Yup. This is a pattern I would use frequently, too. Especially important across module boundaries or for limiting view refreshes.

The two recommendations are to a) use computed properties, or b) use this pattern:

@Philippe_Hausler

However if you do have a need to (in non SwiftUI scenarios) to do something similar then the use for the withObservationTracking (note; it got changed to a free floating function).

func resetObservationOnExternalObservable() {
    ObservationTracking.withTracking {
      self.dependentProperty = "\(external.indirectlyObservedProperty). Woohoo!"
    } onChange: { [weak self] in
      // The onChange is fired on the willSet side of things - so the reset needs to be called asynchronously to prevent a recursion and also update after the property changes.
      Task { @MainActor in
        self?.resetObservationOnExternalObservable()
      }
    }
  }

However, method A suffers from unnecessary view refreshes, while method B suffers from the async hop (which is one of the reasons async sequences were dropped) which will cause broken view invariants/ non synchronised view updates. I wrote a bit more about that here.