@ObservedObject Equivalent

[s-k]

Is there an equivalent to @ObservedObject from SwiftUI? If not, how would I update the UI when a property in the model changes?

[david-swift]

You can use @State, it automatically updates the UI when the property it wraps changes.

If you want to create a model grouping multiple properties into one property, you can use a value instead of a reference type, and updates will work fine.

import Adwaita

struct CounterModel: Codable {

    var count = 0 {
        didSet {
            print(count)
        }
    }

}

struct CounterDemo: View {

    @State("count", folder: "io.github.AparokshaUI.Demo/count")
    private var count = CounterModel()

    var view: Body {
        VStack {
            HStack {
                CountButton(count: $count.count, icon: .goPrevious) { $0 -= 1 }
                Text("\(count.count)")
                    .style("title-1")
                    .frame(minWidth: 100)
                CountButton(count: $count.count, icon: .goNext) { $0 += 1 }
            }
            .halign(.center)
        }
        .valign(.center)
        .padding()
    }

    private struct CountButton: View {

        @Binding var count: Int
        var icon: Icon.DefaultIcon
        var action: (inout Int) -> Void

        var view: Body {
            Button(icon: .default(icon: icon)) {
                action(&count)
            }
            .style("circular")
        }
    }

}

[david-swift]

@State is for views, structs conforming to WindowSceneGroup, and apps only.

The delegate is actually a good point. I'll see whether I can find a solution based on the observation framework, but I'm currently rather busy so don't expect a result too fast. Thanks for starting this discussion!

[david-swift]

It should be possible without it (view updates seem to work also with reference instead of value types), and most often, view models are probably used on the app (that is created once the app starts and won't be initialized anymore after that) instead of a view, it can be used as a regular property without a wrapper. But I agree that there should be an easy-to-use solution similar to observed object that can be used in views.

[s-k]

Can you elaborate a little, how your suggested solution for reference types would look like? I'm not exactly sure what you mean.

[david-swift]

If your view model is in an app, you could use the following approach:

import Adwaita
import Observation

@Observable
class ViewModel {

    var count = 0

}

@main
struct AdwaitaTemplate: App {

    let id = "io.github.AparokshaUI.AdwaitaTemplate"
    var app: GTUIApp!
    let viewModel = ViewModel()

    init() {
        observe()
    }

    var scene: Scene {
        Window(id: "main") { _ in
            Text("\(viewModel.count)")
                .padding()
            Button("+1") {
                viewModel.count += 1
            }
            Button("-1") {
                viewModel.count -= 1
            }
        }
    }

    func observe() {
        withObservationTracking {
            viewModel.count
        } onChange: {
            Task {
                State<Any>.updateViews(force: true)
                observe()
            }
        }
    }

}

In views, you can use:

import Adwaita
import Observation

@Observable
class CounterModel {

    var count = 0 {
        didSet {
            print("Hi")
        }
    }

}

struct CounterDemo: View {

    @State private var count = CounterModel()

    init() {
        observe()
    }

    var view: Body {
        VStack {
            HStack {
                CountButton(icon: .goPrevious) { count.count -= 1 }
                Text("\(count.count)")
                    .style("title-1")
                    .frame(minWidth: 100)
                CountButton(icon: .goNext) { count.count += 1 }
            }
            .halign(.center)
        }
        .valign(.center)
        .padding()
    }

    private struct CountButton: View {

        var icon: Icon.DefaultIcon
        var action: () -> Void

        var view: Body {
            Button(icon: .default(icon: icon)) {
                action()
            }
            .style("circular")
        }
    }

    func observe() {
        withObservationTracking {
            count.count
        } onChange: {
            Task {
                _count.content.storage.update = true
                State<Any>.updateViews()
                observe()
            }
        }
    }

}

Both approaches are too complicated, so I'll make a view, "scene", or app automatically check whether there are observable children and observe them, similar to the approach I used for @State. And, make sure that the "original" state doesn't overwrite the new one after the initialization of a view as this is the case with @State, but pass it to the initializer before (maybe I can also improve @State performance-wise). I'll write here once the solution is available, I imagine it to look like the following:

import Adwaita
import Observation

@Observable
class CounterModel {

    var count = 0 {
        didSet {
            print("Hi")
        }
    }

}

struct CounterDemo: View {

    let count = CounterModel()

    var view: Body {
        VStack {
            HStack {
                CountButton(icon: .goPrevious) { count.count -= 1 }
                Text("\(count.count)")
                    .style("title-1")
                    .frame(minWidth: 100)
                CountButton(icon: .goNext) { count.count += 1 }
            }
            .halign(.center)
        }
        .valign(.center)
        .padding()
    }

    private struct CountButton: View {

        var icon: Icon.DefaultIcon
        var action: () -> Void

        var view: Body {
            Button(icon: .default(icon: icon)) {
                action()
            }
            .style("circular")
        }
    }

}

[s-k]

Thank you very much for the detailed explanation! This helps me a lot!

[david-swift]

I added support for the observation framework on the 1.0.0 branch for the next major version as the implementation required some breaking changes. I decided to make State handle both value types and observable reference types:

import Adwaita
import Observation

@Observable
class CounterModel {

    var count = 0 {
        didSet {
            print("Hi")
        }
    }

}

struct CounterDemo: View {

    @State private var count = CounterModel()

    var view: Body {
        VStack {
            HStack {
                CountButton(icon: .goPrevious) { count.count -= 1 }
                Text("\(count.count)")
                    .style("title-1")
                    .frame(minWidth: 100)
                CountButton(icon: .goNext) { count.count += 1 }
            }
            .halign(.center)
        }
        .valign(.center)
        .padding()
    }

    private struct CountButton: SimpleView {

        var icon: Icon.DefaultIcon
        var action: () -> Void

        var view: Body {
            Button(icon: .default(icon: icon)) {
                action()
            }
            .style("circular")
        }
    }

}

[david-swift]

Hello @s-k,

I changed the plan a bit after my last answer. Instead of adding support for the observation framework (which makes tracking changes way more difficult than with value types), I'll use an own value type approach which integrates better with the state system.

The only time when a reference type is sensible is when having to update a property from inside the reference type itself in a closure, right? Something like this:

@Observable
class SomeModel {

    var property: String

    func updateProperty {
        Task {
            // Do something
            Idle {
                property = "Hello"
            }
        }
    }

}

I'll make adwaita-swift a backend based on Meta in the 1.0.0 release, where I solved this using the Model protocol (which means all the work currently on the 1.0.0 branch will not be in the 1.0.0 release actually).

struct SomeModel: Model {

    var property: String
    var model: ModelData?

    func updateProperty {
        Task {
            // Do something
            Idle {
                setModel { $0.property = "Hello" }
            }
        }
    }

}

The advantage is that changes to the model type from outside the model can be observed in the same way as any changes, and the changes inside of the model (such as in the example) are also simpler to track.

If you see a problem with this approach, I'd be glad if you could share it!

[s-k]

Hello @david-swift,

Thank your for your continuing work on this problem! I have a few comments on your proposed solution:

First, I share your preference to use structs over classes if possible. It limits the sharing of mutable state and makes code more predictable. However, in some cases, classes are the best tool. Examples would be:

• Stores that manage data shared by multiple parts of the app
• Objects that guard access to external resources such as files, databases, etc.
• Objects that act as delegates for delegate-based APIs
• Re-using existing code that has used classes for any reason

Therefore, a UI framework should work with both struct and class models.

Am I correct in thinking that Model can only be conformed to by structs? I think this would be a problem. Maybe you could somehow make your proposal work with class models. At first, I thought you could do it this way, but this throws a compiler error (and it would be a lot of boilerplate):

class RealModel {
    private(set) var state: State = .loading {
        didSet {
            for listener in stateChangeListeners {
                listener(state)
            }
        }
    }
    
    private var stateChangeListeners: [(State) -> Void] = []

    enum State {
        case loading
        case ready
    }

    func somethingDidHappen() {
        state = .ready
    }
    
    func subscribeToStateChanges(_ listener: @escaping (State) -> Void) {
        stateChangeListeners.append(listener)
    }
}

struct FakeModel: Model {
    var realModel: RealModel
    var state: RealModel.State
    var model: ModelData?
    
    init(realModel: RealModel) {
        self.realModel = realModel
        self.state = realModel.state
        
        realModel.subscribeToStateChanges { newState in // ERROR: Escaping closure captures mutating 'self' parameter
            setModel { $0.state = newState }
        }
    }
}

Maybe you could store the View or '@State' inside the real model and call setModel() this way, but it wouldn't be nice and could maybe could lead to problems when the view is changed!?

Second, I had looked at the way you implemented the support for @Observable. I believe this is not the way SwiftUI does it. If my understanding is correct, you could just nest every line you evaluate the view property of a View inside withObservationTracking(). Then, in onChange you just invalidate the view, i.e., mark it to be re-evaluated. This would look something like this:

let body: Body = withObservationTracking {
    view.view
} onChange: {
    // Mark view for re-evaluation
    // This is called in `willChange`. This means, the values have not changed yet. So you would have to call these asynchronously:
    Task { @MainActor in // or use something like `Idle`
        StateManager.updateState(id: id)
        StateManager.updateViews(force: forceUpdates)
    }
}
// Use `body` to construct the UI

I am not very familiar with your code but maybe in your case you would change the content() call in StateWrapper.update() to something like this:

let evaluatedContent: Body = withObservationTracking {
    content()
} onChange: {
    ...
}
evaluatedContent
    .widget(modifiers: modifiers)
    .update(storage, modifiers: modifiers, updateProperties: updateProperties)

and change StateWrapper.container() in a similar way.

This also has the advantage that users do not have to put the @Observable model inside @State. They can just use any @Observable inside view and any change in the model automatically causes the view to update.

[david-swift]

• Stores that manage data shared by multiple parts of the app

Normally, one should do this by setting the state to a common parent view. However, I see that this could result in a lot of boilerplate so I might see whether I can add the option to manually set the identifier and use the same state in different views:

struct SomeView: View {

    @State(id: "test") private var test = "Hi"

    var view: Body {
        // ...
    }

}

struct AnotherView: View {

    @State(id: "test") private var test2 = "Hi"

    var view: Body {
        // ...
    }

}

The two state properties would then actually access the same state value.

---

• Objects that guard access to external resources such as files, databases, etc.
• Objects that act as delegates for delegate-based APIs

In those cases, you can implement a set up function with a binding or a callback and add the object as a child (the binding does not affect conformance to protocols etc.):

struct SomeModel: Model {

    var property = "Test"
    var object: TestCallbackObject!

    var model: ModelData?

    mutating func setup() {
        object = .init(property: binding.property)
    }

}

class TestCallbackObject {

    @Binding var property: String

    init(property: Binding<String>) {
        self._property = property
    }

}

---

• Re-using existing code that has used classes for any reason

It has to be converted - but I do not expect it to be too difficult in most cases.

---

you could just nest every line you evaluate the view property of a View inside withObservationTracking().

No, because of views such as List which have a closure (see initializer) that does not get executed when initializing. Therefore, occurrences of references within those closures will not be recognized.

[s-k]

@david-swift Thank you for your hint and sample code regarding the set up function! It's not exactly what I was looking for, but it has to suffice.

No, because of views such as List which have a closure (see initializer) that does not get executed when initializing. Therefore, occurrences of references within those closures will not be recognized.

SwiftUI has the same problem. You would need to add another call to withObservationTracking() in each line ListBox.content is evaluated.