View Not Updating on resetCounters Despite _printChanges Showing Correct State

[topkim993]

Hi everyone,

I’m having an issue where resetting a list of counters in TCA doesn’t update the SwiftUI view, even though _printChanges() shows the state updating correctly. Looking for help!

Problem

• App starts with counters at [1, 0].
• Press "+" to make it [2, 0] — view updates fine, _printChanges() logs it.
• Press "Reset Counters" — _printChanges() shows [1, 0], but the view stays at [2, 0].

What I’ve Noticed

• Individual counter changes (e.g., increment) update the view perfectly.
• resetCounters updates the state (per _printChanges()), but the view doesn’t reflect it.

Questions

• Why doesn’t the view update after resetCounters?

Info

• Xcode: 16.1
• TCA: 1.16.1

@Reducer
struct CounterListFeature {
    @ObservableState
    struct State: Equatable {
        var defaultCounters: IdentifiedArrayOf<CounterFeature.State> = []
        var counters: IdentifiedArrayOf<CounterFeature.State> = []
    }

    enum Action {
        case onAppear
        case resetCounters
        case counter(IdentifiedActionOf<CounterFeature>)
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .onAppear:
                state.defaultCounters = IdentifiedArray(
                    uniqueElements: [
                        CounterFeature.State(id: UUID(), count: 1),
                        CounterFeature.State(id: UUID(), count: 0)
                    ]
                )
                state.counters = state.defaultCounters
                return .none
            case .resetCounters:
                state.counters = state.defaultCounters
                return .none
            case .counter:
                return .none
            }
        }
        .forEach(\.counters, action: \.counter) {
            CounterFeature()
        }
        ._printChanges()
    }
}

struct CounterListView: View {
    let store: StoreOf<CounterListFeature>

    var body: some View {
        VStack {
            Button("Reset Counters") {
                store.send(.resetCounters)
            }

            ForEach(store.scope(state: \.counters, action: \.counter)) { store in
                CounterView(store: store)
            }
        }
        .onAppear {
            store.send(.onAppear)
        }
    }
}

@Reducer
struct CounterFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
        let id: UUID
        var count: Int
    }

    enum Action {
        case increment
        case decrement
        case reset
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .decrement:
                state.count -= 1
            case .increment:
                state.count += 1
            case .reset:
                state.count = 0
            }
            return .none
        }
    }
}

struct CounterView: View {
    let store: StoreOf<CounterFeature>

    var body: some View {
        VStack {
            Text("\(store.count)")
            HStack {
                Button("-") { store.send(.decrement) }
                Button("+") { store.send(.increment) }
            }
            Button("Reset") { store.send(.reset) }
        }
    }
}

[topkim993]

This works

case .resetCounters:
    state.counters = IdentifiedArray(
        uniqueElements: state.defaultCounters.map {
            CounterFeature.State(id: $0.id, count: $0.count)
        }
    )
    return .none

Not sure why it needs map instead of just state.counters = state.defaultCounters.

I thought structs being copied would avoid issues, and _printChanges() shows the change, so I’m confused why state.counters = state.defaultCounters doesn’t update the view.

[pyrtsa]

This is starting to look to me like a soundness issue with @ObservableState. It has little or nothing to do with IdentifiedArray and everything with observation macros silently turning struct State into a reference-semantic type! 🤯

You get a similarly broken experience with this simpler wrapper around CounterListFeature (and …View):

@Reducer
struct SingleCounterFeature {
    @ObservableState
    struct State: Equatable {
        let `default` = CounterFeature.State(id: UUID(), count: 0)
        var counter: CounterFeature.State?
    }

    enum Action {
        case reset
        case counter(CounterFeature.Action)
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .reset:
                state.counter = state.default
                // Uncomment to work around the issue:
                //state.counter = .init(id: state.default.id, count: state.default.count)
                return .none
            case .counter:
                return .none
            }
        }
        .ifLet(\.counter, action: \.counter) {
            CounterFeature()
        }
        ._printChanges()
    }
}

struct SingleFeatureView: View {
    let store: StoreOf<SingleCounterFeature>

    var body: some View {
        VStack {
            Button("Reset Counters") {
                store.send(.reset)
            }

            if let store = store.scope(state: \.counter, action: \.counter) {
                CounterView(store: store)
            }
        }
    }
}

The reason assigning with state.default fails but making a (not-really-)"copy" of it succeeds is because the macro-expanded CounterFeature.State carries an additional reference-semantic property:

@ObservationStateIgnored var _$observationRegistrar = ComposableArchitecture.ObservationStateRegistrar()

public var _$id: ComposableArchitecture.ObservableStateID {
    _$observationRegistrar.id
}

whose identity (_$id) remaining unchanged prevents the parent store from updating the scoped child store with didSet, see here: https://github.com/pointfreeco/swift-composable-architecture/blob/1.17.1/Sources/ComposableArchitecture/Store.swift#L392-L408.

---

Having thought about this a while, I can't see how _$observationRegistrar can soundly be a member of any value type; I'd rather expect it to live as a member of the surrounding reference type like Store, which is where the mutations actually observably happen.

I'd like to bring to attention this quote by John McCall because it feels like it's exactly the issue ComposableArchitecture has hit with its current way of performing state observation:

Adding observing accessors to an individual variable is extrinsic to the value stored in the variable and doesn't contradict my point at all. If you add that to a struct member, though, it's probably going to have a lot of unwanted non-value-like behavior.

(There are generally many good comments around the topic if you browse up and down that same Swift Forums thread, btw.)

[topkim993]

Thanks for the detailed explanation! It seems like there’s no way around this issue for now. Are there any alternative approaches to avoid this problem?

[pyrtsa]

Some alternatives that I can think of (without truly recommending any):

• Instead of return .none after resetting state.counters, sending some action to all child reducers triggers their state. (In this case, .reset seems logical, but any action should do.)
• In general, not modifying a child reducer's state from a parent reducer seems like it might avoid these issues. 🤔
• For all counters that you modify from the parent reducer, you can apparently also trigger a view refresh by calling state.counters[id: id]?._$willModify() in addition. That effectively changes their _$id to a new value, but seems like a dirty hack. 🤷‍♂️

That last note actually lead me to another place that seems buggy in TCA as of 1.17.1: When I call state.counter = state.default in my previous snippet, the debugger steps into the following stack frames, another place where TCA avoids notifying ObservationRegistrar about a mutation to the \.counter key path (because _$id values before and after compare equal; see stack frames 0, 1, and 2):