Comparing @Observable to ObservableObjects in SwiftUI

[@andresraigoza2082]

I found very useful the idea of thinking that @State is telling SwiftUI who owns that object. I'll never forget that, thank you so much!

[@larschristiansen3136]

Thank you for this video. The reason why an object can sometimes be a let and not a var has puzzled me, but thanks to your video I now understand why.

[@DonnyWalsdev]

Thanks! So happy the video was able to clear this up. I think it's pretty much one of the major things people trip over with the new macro

[@w0mblemania]

This was very useful. Thanks.

[@DonnyWalsdev]

Thank you!

[@JosephHeck]

Lovely video overview, although your use of "we" and "you" when describing ownership and what's acting on what in comparing the differences was a bit confusing in places. I'm not yet using @Observable myself, more because of the brutal hit to compile time with macros, but I also want a shared observation publisher setup in a couple of places, which (as you mentioned near the end) Observable doesn't have anything to help with.

[@DonnyWalsdev]

Thanks! Would you say that either we or you works better, and is there one that would be best? Or do you feel like I mixed them up in a confusing way but using both in a video is okay?

[@JosephHeck]

@@DonnyWalsdev I'd suggest not using either - that's what I found confusing. You started with 'you', talking about ownership and @State and how that transfers things, and clarified it a bit later that the view "owned" that variable. It would have been more clear if you started off with "your code" owning that, instead of "you" and then switched to clarify that with @state, the view "owns" the reference and manages its lifecycle. That's one of the key differences in the new semi-defunct ObservableObject vs StateObject - you touch on it well with the newest Observation bits, but it was just confusing getting there.

[@DonnyWalsdev]

@@JosephHeckThanks! That makes a lot of sense :) I appreciate that you took the time to explain what you meant, I'll pay attention to that going forward!

[@aalecaar]

Thank you so much for this video, Donny! I have a question. You said we should use @State if the view owns the @Observable object. However, the following code works perfectly fine, even tough it was not marked with @State: @Observable class MyCounter { var count = 0 } struct ContentView: View { private let counter = MyCounter() var body: some View { VStack { Button(action: { counter.count += 1 }, label: { Text("Increment") }) Text("The counter is \(counter.count)") } } } You gave a great and clear explanation about the fact that we use @State if the object is within a view that is itself a subview, and we want to persist its value if the parent view updates. But let’s suppose we are sure the view from the example above won’t be a nested view. We also know that this view owns the object. But given the fact that everything works normally without using @State, is there really a good reason to use it besides the case when the object is in a subview and we don’t want to lose its value if a parent view updates? And thank you again for your video, it helps a lot.

[@DonnyWalsdev]

Thanks for watching! Yes, the good reason here IMO is semantics. Using @Stare will clearly mark the ownership and intent and will help prevent problems in the future if your view does get reinitialized because something changed over time. You’re absolutely right that your example will work if you know the view never gets reinitialized but we should always assume that our views might need to be reinitialized and make sure that our code handles that correctly

[@aalecaar]

@@DonnyWalsdev Semantics makes perfect sense. Seems like a good practice to follow. It's like the same reason why you make private the things that don't need to be exposed. I appreciate your time and patience:)

[@alperenunal3975]

Hey, nice video 🎉 should i use @observationIgnored property wrapper for non tracked properties in observable macro object ? Is observable macro handles itself ?

[@DonnyWalsdev]

You only need ObservationIgnored if you want to be able to use a property in a view and assign values to it without having the view redraw. If no view uses the property at all then the views won’t update when you assign to a property that isn’t ObservationIgnored