How best to present vanilla MVVM feature from TCA parent?

[jonduenas]

How are people presenting vanilla Observable view model features from TCA parent features? I know it's been strongly suggested to not hold reference type state like a view model in TCA state. But this then presents a challenge in managing the view model lifecycle, and you’re forced to create a wrapper view to hold the view model with @State to then pass to the child view. This is all reasonable until you then need to also seed the view model with data, and there is well known documentation on why seeding @State from the outside is challenging.

But to add to the challenge, I’m trying to seed the view model with Shared state. Because of how Shared works with Equatable, two Shared types are equal if their values are equal. But, their backing reference might not be the same. So if you try to use onChange like suggested by Chris in the link I shared, you get some strange behavior. Here is some code to demonstrate this...

struct Foo: Equatable {
    var value: Int = 0
}

@Reducer
struct ParentFeature {
    @ObservableState
    struct State {
        @Shared var foo: Foo
        var childFeature: Shared<Foo>?

        init(foo: Foo = Foo()) {
            _foo = Shared(value: foo)
        }
    }

    enum Action {
        case pushChildButtonTapped
        case swapChildButtonTapped
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .pushChildButtonTapped:
                state.childFeature = state.$foo
                return .none
            case .swapChildButtonTapped:
                state.childFeature = Shared(value: .init())
                return .none
            }
        }
    }
}

struct ParentView: View {
    @Bindable var store: StoreOf<ParentFeature>

    var body: some View {
        VStack {
            Text("Parent Foo Value: \(store.foo.value)")

            Button("Push Child") {
                store.send(.pushChildButtonTapped)
            }

            Button("Swap Child") {
                store.send(.swapChildButtonTapped)
            }

            if let child = store.childFeature {
                Text("childFeature value: \(child.wrappedValue.value)")
                ChildWrapperView(foo: child)
            }
        }
    }
}

@Observable @MainActor
final class ChildViewModel {
    @ObservationIgnored
    @Shared var foo: Foo

    init(foo: Shared<Foo>) {
        _foo = foo
        print("ChildViewModel.init")
    }

    deinit {
        print("ChildViewModel.deinit")
    }
}

struct ChildWrapperView: View {
    @State private var viewModel: ChildViewModel?

    private let foo: Shared<Foo>

    init(foo: Shared<Foo>) {
        self.foo = foo
    }

    var body: some View {
        ZStack {
            if let viewModel {
                ChildView(viewModel: viewModel)
            }
        }
        .onChange(of: foo, initial: true) { _, newValue in
            print("onChange(of:) newValue: \(newValue)")
            viewModel = .init(foo: newValue)
        }
//        .onAppear {
//            viewModel = .init(foo: foo)
//        }
    }
}

struct ChildView: View {
    @Bindable var viewModel: ChildViewModel

    var body: some View {
        VStack {
            Stepper("Foo", value: $viewModel.foo.value)
            LabeledContent("Foo Value", value: viewModel.foo.value, format: .number)
        }
        .padding()
    }
}

#Preview {
    ParentView(
        store: Store(
            initialState: .init(),
            reducer: {
                ParentFeature()
            }
        )
    )
}

Screen.Recording.2025-12-26.at.1.32.52.PM.mov

If "Swap Child" is tapped right after "Push Child" while the underlying values are equal, SwiftUI doesn't see it as a changed value, so it doesn't trigger .onChange, and the child view model's Shared reference is still pointed to the original parent Shared value. So when you increment the stepper, it first modifies the parent value, which triggers onChange which then updates the view model with the correct Shared reference, and then everything starts working as it should.

If I remove onChange and use either State(initialValue:) in the init or onAppear to init the view model, then tapping "Swap Child" just never updates the underlying reference, and it will always update the original Shared value, which is worse.

Admittedly this example might be convoluted but any potential solution has some downside or scenarios where it doesn't work correctly. Am I missing some better approach for this that doesn't have tradeoffs?

[GreatApe]

So to clarify:

• The reason you use Shared is that you want to be able to change the foo value in the parent, from the child?
• Is the parent foo and the child foo supposed to be independent?
• What is the reason you want to recreate the child vm anytime the value changes? Rather than just changing its value?
• Similarly, why do you want to replace the entire Shared box from the parent, when the wrapped value changes? It seems like this is the root of your troubles.

Also, what is the reason you want to mix TCA and normal MVVM in the first place?

[jonduenas]

So to clarify:

• The reason you use Shared is that you want to be able to change the foo value in the parent, from the child?
• What is the reason you want to recreate the child vm anytime the value changes? Rather than just changing its value?
• Similarly, why do you want to replace the entire Shared box from the parent, when the wrapped value changes? It seems like this is the root of your troubles.

Correct. The parent holds the source of truth.

Imagine a scenario like a parent with a Shared array of values and you want to pass an individual element to a child and have the element in the array update automatically. And then imagine you swap out the element with a different element.

I suppose the real answer is that if Foo in my example was Identifiable and the ID wasn't equal, then onChange would in fact trigger and everything would work correctly. So maybe my example is even more convoluted than I thought. But, I don't think it's completely out of the realm of possibility. There's still a possibility that you could copy the exact value into a new Shared instance and trigger this problem still.

Also, what is the reason you want to mix TCA and normal MVVM in the first place?

There are apps out there that are transitioning, or for reasons, only has certain features in TCA. It's maybe not ideal having a mix as a long term goal, but even short-term this could be a problem in the real world.

[jonduenas]

The more I try and make this more realistic to real-world scenarios, the more I see Identifiable mostly solves this. Technically you could do things like create a freestanding Shared instance with a copied value with the same ID and everything, but I can't think of a real world way this would happen other than just straight up programmer errors that wouldn't be correct behavior in any scenario. The real world scenario of an array of identifiable elements where you swap the element passed to the child, the ID not being equal would correctly trigger the new view model init.

You'd have to have some scenario where you're using things like array indices to pull data from an array that has elements inside that have duplicate values like [2, 2 ,2] or something. If you pulled array[0] and then swapped it with array[1], you'd have this problem. But, real world using SwiftUI and its reliance on Identifiable elements pushes you towards a solution anyways.

But, technically, Shared behaving like a value type while actually being a reference type creates problems like this where it's difficult to know if you're working with the exact same reference without accessing the underscored _objectIdentifier property. Perhaps this should be better moved to the Sharing library's discussions.

[jonduenas]

I don't know if the root problem I'm trying to solve here is "What do you do with reference state in TCA?" or "How do you deal with Shared acting like a value type while actually being a reference type?" I realize that's kinda the selling point for both of these libraries. But it creates these edge case scenarios.

[GreatApe]

If you don't need to change which underlying foo you are pointing to while already showing the child, it's easy, just use the StateObject trick. Then your VM will only be created once, and neither VM nor Shared will be recreated. The only thing is that it won't notice when you switch foo on the go. For that to work, you add an .id() on the ChildView, in fact outside of it, that changes when you change which foo you are controlling.

The StateObject thing is often useful for situations when you want to pass in the initial state of a child vm, but at the same time want the child view to own its own vm.

struct Foo: Equatable {
    var value: Int = 0
}

@Reducer
struct ParentFeature {
    @ObservableState
    struct State {
        @Shared var foos: [Foo]
        var child: Int? = nil

        init() {
            _foos = Shared(value: [.init(), .init(), .init()])
        }
    }

    enum Action {
        case hideChildButtonTapped
        case select0ButtonTapped
        case select1ButtonTapped
        case select2ButtonTapped
    }

    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .hideChildButtonTapped:
                state.child = nil
                return .none

            case .select0ButtonTapped:
                state.child = 0
                return .none

            case .select1ButtonTapped:
                state.child = 1
                return .none

            case .select2ButtonTapped:
                state.child = 2
                return .none
            }
        }
    }
}

struct ParentView: View {
    let store: StoreOf<ParentFeature>

    var body: some View {
        VStack(spacing: 20) {
            Text("Foo Value 0: \(store.foos[0].value)")
            Text("Foo Value 1: \(store.foos[1].value)")
            Text("Foo Value 2: \(store.foos[2].value)")

            HStack {
                Button("Show 0") {
                    store.send(.select0ButtonTapped)
                }

                Button("Show 1") {
                    store.send(.select1ButtonTapped)
                }

                Button("Show 2") {
                    store.send(.select2ButtonTapped)
                }
            }

            Divider()

            if let childIndex = store.child {
                Button("Hide Child") {
                    store.send(.hideChildButtonTapped)
                }

                let childFoo = store.$foos[childIndex]
                ChildView(foo: childFoo)
                    .id(childIndex)
            }
        }
    }
}

import Combine

@Observable @MainActor
final class ChildViewModel: ObservableObject {
    @ObservationIgnored
    @Shared var foo: Foo

    init(foo: Shared<Foo>) {
        _foo = foo
        print("ChildViewModel.init")
    }

    deinit {
        print("ChildViewModel.deinit")
    }
}

struct ChildView: View {
    @StateObject var viewModel: ChildViewModel

    init(foo: Shared<Foo>) {
        // This viewModel will only be created once
        self._viewModel = .init(wrappedValue: .init(foo: foo))
    }

    var body: some View {
        VStack {
            Stepper("Foo", value: $viewModel.foo.value)
            LabeledContent("Foo Value", value: viewModel.foo.value, format: .number)
        }
        .padding()
    }
}

#Preview {
    ParentView(
        store: Store(
            initialState: .init(),
            reducer: {
                ParentFeature()
            }
        )
    )
}

[jonduenas]

I think conforming my view model to ObservableObject just to take advantage of StateObject's autoclosure is not really ideal. But yeah, won't nitpick that. The use of .id is another way to solve this if the elements themselves aren't Identifiable.

My main take away is that Identifiable largely helps this sort of issue. The fact that Shared is reference-like means it has some of the same issues that reference types have. I started to consider how I'd solve this if I wasn't using Shared and was using a normal reference type. Swapping out the reference to something else would still be just as big of an issue, and solving it would have to go down the path of how to use Identifiable and Equatable on reference types, which is a can of worms. So, happy to concede this boils down to using reference types for sharing state is complicated, and Sharing obviously helps with a ton of it but not everything, and the only real perfect solution is to not use a reference type at all, otherwise you just have to be careful about keeping track of references.

[GreatApe]

ObservableObject doesn't have any requirements, so it's very safe and cheap to add.

I think the fact that Shared behaves like a reference is a very strong reason not to recreate it all the time, that's something you should only do with structs. So however you want to solve this, you definitely shouldn't be recreating VMs and Shared. That goes against the whole idea I would say. The point of a reference type is that you create it once and use it multiple times, potentially from different places, exactly like here.

I am not sure how Identifiable makes a difference here -- unless you are in a ForEach I don't think it matters if Foo is Identifiable or not, it won't affect rendering. What matters is the .id. Or what is it that you would make Identifiable?

[jonduenas]

ObservableObject doesn't have any requirements, so it's very safe and cheap to add.

But it adds things you don't need. Also, it's tying the view model to a specific work-around implementation detail that is completely separate from any requirements of the model.

Also, I'm generally not a fan of using StateObject like this at all. And it doesn't particularly feel like you gain much compared to just using State with the given workaround. Which to be fair is pretty unclean of a solution too. But it at least doesn't leak into outside contexts.

I think the fact that Shared behaves like a reference is a very strong reason not to recreate it all the time, that's something you should only do with structs. So however you want to solve this, you definitely shouldn't be recreating VMs and Shared. That goes against the whole idea I would say. The point of a reference type is that you create it once and use it multiple times, potentially from different places, exactly like here.

I'm not sure what part suggests recreating view models or shared values unnecessarily.

I am not sure how Identifiable makes a difference here -- unless you are in a ForEach I don't think it matters if Foo is Identifiable or not, it won't affect rendering. What matters is the .id. Or what is it that you would make Identifiable?

In the specific example I shared, adding an ID to Foo uniquely identifies it apart from value, and so if you swap it out, even if the value integer were the same, the ID would be different and so the onChange would trigger. Your example is, essentially, the same end result.

[GreatApe]

But it adds things you don't need.

ObservableObject doesn't add anything to your compiled code as far as I know, you can see it as a marker protocol. But I agree that it's a bit of a shame to have to use it. Hard to see why you'd object to using StateObject though, it was made specifically for storing reference types while letting the View manage the life cycle, it's a perfect fit.

I'm not sure what part suggests recreating view models or shared values unnecessarily.

You explicitly create a new instance of the VM every time the underlying value changes. If the ViewModel has any other state in it, that will not work since it will be reset all the time:

        .onChange(of: foo, initial: true) { _, newValue in
            print("onChange(of:) newValue: \(newValue)")
            viewModel = .init(foo: newValue)
        }

Even if you have a philosophical aversion to StateObject, I don't see why you'd want to re-instantiate the VM all the time. To be honest I don't understand the reason for the wrapperview either.

When it comes to your onChange and identifiable, it is triggered by the instance being unequal to its former value, so it's not related to the Identifiable protocol. You could add any property with any name and type, as long as they are different for the different foos.

[jonduenas]

ObservableObject doesn't add anything to your compiled code as far as I know, you can see it as a marker protocol. But I agree that it's a bit of a shame to have to use it. Hard to see why you'd object to using StateObject though, it was made specifically for storing reference types while letting the View manage the life cycle, it's a perfect fit.

I'm not gonna get into it, mostly because I don't think it's worth getting into a debate about it here. But using StateObject/State for views that have external dependencies has well documented issues. The fact that we have to bend over backwards to make it work, and even when it's working it's not really a great solution points to this being outside of Apple's intended use for StateObject/State.

You explicitly create a new instance of the VM every time the underlying value changes. If the ViewModel has any other state in it, that will not work since it will be reset all the time:

        .onChange(of: foo, initial: true) { _, newValue in
            print("onChange(of:) newValue: \(newValue)")
            viewModel = .init(foo: newValue)
        }

Even if you have a philosophical aversion to StateObject, I don't see why you'd want to re-instantiate the VM all the time.

I thought this might happen too, and then I tried it, and it's simply not actually what happens. I have a print inside the view model init and it gets called the first time the view appears and any time I swap the shared instance with a new one. But simply modifying Foo.value from either the parent or the child does not cause the view model to be recreated. There may be something else at play here with the Shared type, because I also don't understand why onChange isn't getting called every time, but it isn't.

Try it yourself and let me know if you see something different.

To be honest I don't understand the reason for the wrapperview either.

So TCA doesn't hold a reference type in state. Google it, search past discussions here, read the documentation, it's all over the place and is strongly suggested to avoid it. Sharing library is the closest thing to a reference type that is ok.

When it comes to your onChange and identifiable, it is triggered by the instance being unequal to its former value, so it's not related to the Identifiable protocol. You could add any property with any name and type, as long as they are different for the different foos.

I'm probably not communicating this well enough. I know it's not Identifiable specifically. But, it's using something besides the integer value alone to determine if it was unique.

It's not an all encompassing solution. If for example there was no Foo and everything was just passing an Integer, I'd still have the problem and would have to figure out some other way to uniquely identify things.