I note almost all the examples are made with final class. What happens with a non-final class? Can the subclass properties be observed too? If not, can you add @Observable on subclasses?
3 Likes
The final is used because the protocol requirements having Self in the keypath require that the types be final. There are ways that could be relaxed, however doing so may have some pretty steep impact - namely creating ambiguity over what keypath it is referring to; either the subclass or the superclass.
As currently proposed the requirement is that classes must be final.
1 Like
So if you have a class hierarchy, you can only add @Observable on leaf classes (which must be final). That's a limitation I could not find in the proposal. Thank you for clarifying.
Now I wonder what this means for properties of a base class. Do they become observable when @Observable is applied on the derived class? I don't see how that'd work, so I suppose there are other ways to make them observable, perhaps by overriding them in the derived class?
I'm trying to see if @Observable can work (reasonably) with a class hierarchy, and it would appear the answer is mostly no. To me this is a very major downside of this proposal.
3 Likes
macros only apply to the properties that are members to the application, so it does not apply to superclasses (since macros don't mutate code, they only add to it)
1 Like
That's quite serious limitation IMHO. As far as I understand the previous version of the pitch was not using macros and it didn't have this limitation, right? Can you list all pros and cons the new macro based implementation has compared to the one that doesn't use macros.
1 Like
I guess my followup question is whether it's possible to manually implement observability in those cases. Perhaps like this:
class Base {
var value: Int // non-observable value in base class
}
@Observable
final class Derived: Base {
// making Base.value observable in derived class
override var value: Int {
get {
_$observationRegistrar.access(self, keyPath: \.value)
return super.value
}
set {
_$observationRegistrar.withMutation(self, keyPath: \.value) {
super.value = newValue
}
}
}
}
Would this work? It's neither convenient nor pretty, but it's good to know there's an escape route when you've painted yourself in a corner.
That will work as you expect.
2 Likes
Cycling back to a few points of feedback:
There is a slightly inaccurate but founded concern about flickering UI. I think it might be better to phrase that as more so the issue underlying that; the concern is consistency. Which is a very reasonable worry. The point of consistency problems crops up (paraphrasing a few posts by folks) that if a property will be observed and the change in that property only happens once (and never happens again) and the confluence of events is such that the property observation via values(for:) is called asynchronously (e.g. in a Task) the first value could get lost.
After working through all of the ramifications and implications of this; there are a few take-aways. 1) that concern is not only reasonable, but also is a true problem. 2) prepending the first value does have some consequence, but in general is probably fine.
Let me iterate what I have discerned:
The first point of iteration should be ideally where any work is done, however... getting that first value MUST occur in the same isolation domain as the access to the object. Furthermore the first value may not be desirable in all circumstances. Lastly, holding that value might incur some sort of lifecycle impact.
Options:
- Hold the
Observabletype and defer access to the first value until the first point of iteration.
This option does not address the missing first value problem but also poses a retain cycle issue. - Grab the initial value immediately at construction.
This option does address the "first value" problem but comes at a cost of extra overhead of storage. This also has an interesting alteration to the protocols; it forces thevalues(for:)to be isolated; because what happens if theObservabletype is@MainActorbound? The keypath based access MUST follow the same rules as the property in question.
In my view option 1 might have an attractive characteristic that it defers access, but since it does not solve the issue it is disqualified.
Option 2 does validly solve the issue. It could be a option to the values(for:) but to be honest if folks don't want that first value... they could just say values(for:...).dropFirst(). But it means that the method for getting values must share the same isolation as the type. Which in the grand scheme of things is probably a reasonable alteration (having it be nonisolated was only really a bonus and not really a core part of the API).
That was all a very long winded way of stating; I agree that providing the first value can be accomplished, and should be part of the behavior for values(for:).
This now brings us to changes(for:). To me it would be strange that values(for:) had an "initial value" but changes(for:) did not. So for the same reasoning that should also have an "initial value". The initial would be claiming that the change went from "observing nothing" to "observing all the items". Meaning that it would emit a change containing all tracked properties of that observation.
I have some additional responses/musing/mulling-over of the synchronous versus asynchronous part of things but I will follow up later with that when my thoughts are a bit more congealed with that.
The behavioral change outlined here will be included with an update to the proposal. As well as an update to the implementation.
Thanks for all of the discussion so far - this is definitely the type of feedback that makes things much more robust and I appreciate your patience with me on navigating all of the feedback.
26 Likes
Is the following going to be improved in the new observation machinery?
class Model: ObservableObject {
@Published var state = 0
@Published var unrelated = 0
init() {
Timer.scheduledTimer(withTimeInterval: 1/100, repeats: true) { [self] _ in
unrelated += 1
}
Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [self] _ in
state += 1
}
}
}
var bodyCount = 0
struct ContentView: View {
@StateObject private var model = Model()
var body: some View {
bodyCount += 1
return VStack {
Text(String(model.state))
}
}
}
In this example body is called 100 times a second, disregarding the fact that ContentView doesn't depend upon "unrelated" variable.
@Philippe_Hausler is the API available in the latest nightly-main toolchain?
The view in this case (when the model side would be using @Observable instead of ObservableObject) will only update once a second, not 100 times a second.
And it would be written as such:
@Observable final class Model {
var state = 0
var unrelated = 0
init() {
Timer.scheduledTimer(withTimeInterval: 1/100, repeats: true) { [self] _ in
unrelated += 1
}
Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [self] _ in
state += 1
}
}
}
var bodyCount = 0
struct ContentView: View {
@State private var model = Model()
var body: some View {
bodyCount += 1
return VStack {
Text(String(model.state))
}
}
}
5 Likes
Hi @Philippe_Hausler,
In your example you mark the Model with the @State property wrapper. This differs from the similar example in the proposal text.
Will it need @State?
For SwiftUI @State represents state that is owned by the view. Observable types can be owned by views or owned externally. If it is owned externally it could be just private var model: Model etc.
3 Likes
Perfect! Thanks for the explanation!
This is a really clean api and much less confusing than StateObject vs ObservableObject vs State.
I love this proposal very much! 
1 Like
I wrote up some ideas that I had about observing changes to move-only struct instances, and I'm posting the link here not to insist that anyone give it more consideration than they care to, but just to make sure that its existence is visible here on this more prominent thread for anyone who is interested but would have missed it otherwise.
@Philippe_Hausler, thank you.
I want to understand the granularity of this. For example If it was:
@Observable final class Model {
struct S {
var related = 0
var unrelated = 0
}
var state = S()
}
...
struct ContentView: View {
@State private var model = Model()
var body: some View {
bodyCount += 1
return VStack {
Text(String(model.state.related))
}
}
}
would the body be recalculated on state.unrelated changes or only on state.related changes?
Secondly, if I set state.related variable to the same value, would it cause body recalculation or not?
3 Likes
I'm excited to see proposal developing! I'd like to revisit this assertion in the proposal:
In reality, having non-observed fields in a type that is observable is uncommon.
This might often be true for UI code, but from the perspective of someone working at the model and controller API level of a large-scale application, this has not been true. I'd strongly encourage you to revise this proposal to provide observability on a per-property basis, but provide a type-level convenience for marking everything observable where desired.
There are three big problems I see with the all-or-none approach:
-
It is valuable for a protocol to be able to declare an observability requirement on a property it introduces. We have widespread use of this with KVO (albeit not compiler-enforced) in the application I work on. If I understand correctly, this would not be possible in the current proposal unless your protocol adds a conformance requirement for full
ObservableObject. This is not an appropriate requirement for most protocols to impose. -
API should be carefully designed to not expose or encourage unintended (and untested) usage patterns. It's important to provide thoughtful observability and notification patterns in your API, and to lead clients to watch for the right changes in the right way at the right time; but the current design makes that hard. Compare this to access control: Swift doesn't default a type's properties to public just because the type is public; you need to be intentional about what you expose.
-
Observability correctness is not free; e.g. as this proposal discusses, sometimes it requires you to add explicit transactionality in your implementation. By making all properties observable you now need to implement correctness even for those which didn't really need observability; and you may forget to do that. In contrast, having per-property observability annotations should lead you to thoughtfully validate and implement correctness for each observable property you expose.
14 Likes
I have to agree based on my experience developing a very large Swift library. For view-models, sure many of the properties are observable. For models and more of the types that have to do with business logic, we have some properties that need to be observable and many that do not.
6 Likes
Is it just a problem of the first value being missed? Could it be that you miss a few values by the time your task runs that starts an observation?
There doesn't seem to be any mention of dynamic member lookup in the proposal. Is it possible to observe a property through the dynamic member subscript?
Also, just want to echo previous clamor for instructions on getting this working on a toolchain. Seems like folks aren't having much luck?
4 Likes