Correct, it is called once (and only once) if any of the accessed properties are about to be set (via willSet). It is worth noting that the
AsyncSequence interface does not aim to solve object synchronization; it only bounds the transactions of properties together into a batched access.
Sadly that behavior had to be dropped due to both performance problems as well as memory impact - basically it was just too expensive to do generally. However if you need that - extracting the value into a computation and manually calling the
withMutation can give a method to solve that (whereas
@Published doesn't even really allow that easily).
Im not sure I follow the question here: are you talking about the
values(for:) or the
withTracking, I presume the former two by the emphasis. The answer is that asynchronous observation needs to be done in a task; but as soon as the iterator is constructed that will establish an observation to manage which properties changed.
ValueObservation in GRDB seems quite similar to the
withTracking fires the
onChange closure with the
willSet of the first property that changes from the properties accessed within the
apply. That ensures animations and such with no additional modification to work.
Notes: I have been working with the SwiftUI team to investigate additional relaxation of that for exploring future directions like
actor support that initial results show that with some modification we might actually be able to do out-of-line animations. But it is worth noting that work is missing a few bits before it can be done and we feel that the current
withTracking and its
willSet callback behavior is ideal to start from.
That section isn't a future directions but instead an involvement from the SwiftUI team to give a preview of the thoughts we are working on. I know that is a bit un-orthodox in comparison to how traditionally SwiftUI stuff is released but to reenforce the statement - the community impact and feedback is really important here and we feel it is impactful enough that we bend the normal schedule of information.
This is perhaps one of the most "wow factor" demos we have been doing - nesting "just works". For example; we initially thought that things like
@State would break observation.. but without any alteration it pretty much just worked. As you can guess folks are really excited about this.
I have an implementation in the main swift repo: swift/ObservationTracking.swift at main · apple/swift · GitHub. It is written in Swift (with some slight call-outs to interoperate with thread local storage, which is handled very gingerly to avoid getting tangled with async/await).