Improved observation with Perception 2.0?

[rcarver]

Hello, wanted to (re)-start the discussion of efficient observation of shared values. This comment sums up the issue:

@shared observation is not minimal, unlike @observable classes and @ObservableState in a TCA reducer. So you will see inefficient observation when you apply @shared to large value types. link

• Is it possible to improve this with Perception 2.0 / the new shouldNotifyObservers feature?
• And/or are there existing techniques to decompose/recompose large value types in a way that can be minimally observed?

[mbrandonw]

Hi @rcarver, I don't think Perception 2.0 helps with this. We would essentially need to recreate what the Store does for @ObservableState within @Shared, as well as have a version of @ObservableState for @Shared.

Currently our view is that this isn't really a problem in practice and not something we are prioritizing. Can you share more information of how this behavior has affected your app?

[rcarver]

Thanks @mbrandonw that makes sense. For reference, here's what I'm working with in my app:

• Using TCA
• It's an image editing app, so imagine dozens of slider values and other settings.
• That whole state is ultimately a single large structure which feeds into a rendering pipeline
• The UI is broken up into various components to modify sub-parts of the model
• Local components such as sliders must be fast
• Changes to any of the state must result in a render in real-time (during slider movement, for example)

Using Shared, it's very convenient to peel of sub-parts of the state for UI components. Those components can modify that sub-state and it's instantly visible at the root to trigger a render. Unfortunately, due to over-observation that means the entire UI updates from any single change.

Here's what I'm currently using to make things work. It's not as much overhead as the pre-Sharing approach of manually copying state up and down the tree, but I'd love to simplify further!

1. Hold local values in ObservableState for any fields from the shared state
2. Manually sync from shared to local state, avoiding setting if the value is equal
3. Trigger that sync process up and down the feature tree when shared state may have changed
4. We can still observe the root value to trigger renders

Here's what that looks like in practice

@Reducer
public struct DemoFeature {
  @ObservableState
  public struct State: Equatable, Refreshable {
    @Shared var document: LargeState
    var isAuditioning: Bool = false
    var isEnabled: Bool = false
    var isModified: Bool = false
    init(
      document: Shared<LargeState>
    ) {
      self._document = document
      self.refreshSelf()
    }
    public mutating func refreshSelf() {
      self.removeDuplicates(\.isAuditioning, self.document.auditioning.isDisable)
      self.removeDuplicates(\.isEnabled, self.document.enablement.isCurrentlyEnabled)
      self.removeDuplicates(\.isModified, self.document.isModified)
    }
  }
  public enum Action: Sendable {
    case isAuditioningChanged(Bool)
    case isEnabledChanged(Bool)
    case resetButtonTapped
  }
  public var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .isAuditioningChanged(isAuditioning):
        state.$document.withLock { $0.auditioning.isDisable = isAuditioning }
        state.refresh()
        return .none
      case let .isEnabledChanged(isEnabled):
        state.$document.withLock { $0.branch.isActive = isEnabled }
        state.refresh()
        return .none
      case .resetButtonTapped:
        state.$document.withLock { $0.reset() }
        state.refresh()
        return .none
      }
    }
  }
}

// Helper to coordinate the "sync" from shared state to local state

public protocol Refreshable {
  mutating func refreshSelf()
  mutating func refreshChildren()
}

extension Refreshable {
  public mutating func refreshSelf() {}
  public mutating func refreshChildren() {}
}

extension Refreshable {
  public mutating func refresh() {
    // Update children first.
    self.refreshChildren()
    // Then self, so all child state is correct if accessed.
    self.refreshSelf()
  }
}

extension Refreshable where Self: ObservableState {
  /// If the new value is the same as the existing value, skip the
  /// assignment which removes an observable observation.
  public mutating func removeDuplicates<T: Equatable>(
    _ keyPath: WritableKeyPath<Self, T>, _ value: T
  ) {
    if value != self[keyPath: keyPath] {
      self[keyPath: keyPath] = value
    }
  }
}

[mbrandonw]

Thanks for sharing more info and this technique. It certainly gives us some things to think about, just not sure when we will dedicate time to it yet.

[rcarver]

Sure thing! I'll keep exploring as well.

Do you plan to add shouldNotifyObservers-like functionality to ObservableState? That would at least remove the removeDuplicates boilerplate here.

This Refreshable pattern isn't so bad within a single feature, it's when the parent has to refresh() all children that it gets error-prone.

[rcarver]

@mbrandonw I had a bit of time to explore this, see attached

It introduces two wrapper types that are a replacement for typical Shared usage, and a very simple method of tracking field accesses.

@ObservedShared var root: Observed<RootValue>

Despite the awkward call site it was an easy and effective replacement in my app, much better than manually tracking these fields!

I'd be happy to keep working on it, do you have any thoughts on correctness, ergonomics, or how it might fit better into existing tools?

TCA Observation Test.zip

[stephencelis]

Thanks for sharing!

I haven't dug too deep, but we've thought about property wrapper observation in the past and the big issue seems to be that you can always drill into the .wrappedValue and accidentally bypass observation. That's why the TCA Store doesn't add observation to its dynamic member lookup and instead depends on @ObservableState.

So I think a good thing to explore is if the @Shared property wrapper can employ some of the Store's tricks when it comes to @ObservableState, and maybe @ObservableState (or @ObservableValue) should be defined in swift-sharing instead of TCA.

[rcarver]

@stephencelis great points, thanks that helps narrow the scope of future explorations a bit. I'll take another pass and report back.

[rcarver]

Some success here? For the demo cases I setup this simple change behaves as well as TCA.

1. Ported TCA's ObservableState to ObservableValue Copy ObservableState from TCA and rename to ObservableValue rcarver/swift-sharing#1
2. Now Shared can skip registering an access for the full value if its already observable Improved observation rcarver/swift-sharing#2
3. Demo app https://github.com/rcarver/tca-sharing-observation-tests/

The more I explore this the more I feel I don't fundamentally understand ObservationRegistrar, so hopefully this is somewhat on the right path!

[rcarver]

@stephencelis @mbrandonw 👋

Here's a demo of improved view observation for TCA and Shared.

• https://github.com/rcarver/tca-sharing-observation-tests

All of the changes are broken into separate branches on my forks. Just wanted to keep this whole experiment isolated from you until it was solid. So, hope you can take a look and see if there are any flaws in the approach.

• rcarver/swift-sharing/improved-observation
• rcarver/swift-composable-architecture/should-notify-observers