{"id":37920,"date":"2022-12-16T14:30:09","date_gmt":"2022-12-16T19:30:09","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=37920"},"modified":"2023-04-21T20:51:51","modified_gmt":"2023-04-22T00:51:51","slug":"swift-pitch-observation","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/12\/16\/swift-pitch-observation\/","title":{"rendered":"Swift Pitch: Observation"},"content":{"rendered":"

Philippe Hausler<\/a>:<\/p>\n

There are already a few mechanisms for observation in Swift. Some of these include Key Value Observing (KVO), or ObservableObject<\/code>; but those are relegated to in the case of KVO to just NSObject<\/code> descendants, and ObservableObject<\/code> requires using Combine which is restricted to Darwin platforms and does not leverage language features like async\/await or AsyncSequence<\/code>. By taking experience from those existing systems we can build a more generally useful feature that applies to all Swift reference types; not just those that inherit from NSObject<\/code> and have it work cross platform with using the advantages from low level language features like async\/await.<\/p>

[…]<\/p>

Combine’s ObservableObject<\/code> produces changes on the leading edge of the will\/did events and all delivered values are before the value did set. Albeit this serves SwiftUI well, it is restrictive for non SwiftUI usage and can be surprising to developers first encountering that restriction.<\/p>

[…]<\/p>

The Observable<\/code> protocol includes a set of extension methods to handle observation. In the simplest, most common case, a client can use the changes(for:)<\/code> method to observe changes to that field for a given instance. […] This allows users of this protocol to be able to observe the changes to specific values either as a distinct step in the chain of change events or as an asynchronous sequence of change events.<\/p>

[…]<\/p>

By default the concept of observation is transitively forwarded; observing a keypath of \\A.b.c.d<\/code> means that if the field .b<\/code> is Observable<\/code> that is registered with an observer to track \\B.c.d<\/code> and so on. This means that graphs of observations can be tracked such that any set of changes are forwarded as an event.<\/p>

[…]<\/p>

The ObservationTracking<\/code> mechanism is the primary interface designed for the purposes to interoperate with SwiftUI. Views will register via the withTracking<\/code> method such that if in the execution of body<\/code> any field is accessed in an Observable<\/code> that field is registered into the access set that will be indicated in the handler passed to the addChangeHandler<\/code> function. If at any point in time that handler needs to be directly invalidated the invalidate<\/code> function can be invoked; which will remove all change handlers registered to the Observable<\/code> instances under the tracking.<\/p>\n

[…]<\/p>\n

A default implementation can be accomplished in generality by a type wrapper<\/a> that intercepts the modifications of any field on the Observable <\/code>. The type wrapper DefaultObservable<\/code> provides default implementations for the type where the associated Observation<\/code> type is ObservationTracking.Token<\/code>. This means that developers have the flexibility of an easy to use interface that progressively allows for more and more detailed control: starting from mere annotation that grants general observability, progressing to delegation to a storage mechanism that manages registering and unregistering observers, to full control of observation.<\/p><\/blockquote>\n\n

David Smith<\/a>:<\/p>\n

There’s a number of issues we ran into with KVO, all around concurrency[…]<\/p><\/blockquote>\n\n

David Smith<\/a>:<\/p>\n

Philippe’s new ObservationTracking<\/code> machinery reads like a shippable spiritual successor to that hack.<\/p><\/blockquote>\n\n

Update (2023-03-20): Philippe Hausler<\/a>:<\/p>\n