ForEach on nested ObservableState silently fails

[watt]

Description

Given a simple feature like this:

@Reducer
struct CounterList {
  @ObservableState
  struct State: Equatable {
    var counters: [Counter] = [.init(count: 0)]

    @ObservableState
    struct Counter: Identifiable, Equatable {
      let id = UUID()
      var count = 0
    }
  }

  enum Action: BindableAction {
    case binding(BindingAction<State>)
  }

  var body: some Reducer<State, Action> {
    BindingReducer()
  }
}

One might expect to be able to write a view that iterates each counter like so:

struct CounterListView: View {
  @Perception.Bindable var store: StoreOf<CounterList>

  var body: some View {
    WithPerceptionTracking {
      VStack {
        ForEach($store.counters) { (counter) in
          WithPerceptionTracking {
            SimpleCounterView(count: counter.count)
          }
        }
      }
    }
  }
}

But I was surprised to see that this compiles, runs without warnings, and doesn't work.

There are at least 2 ways to correct it:

• remove the nested @ObservableState macro
• use the scope() method to derive a child store collection instead of iterating the array directly

Is this broken? Or is this expected behavior, and what I've constructed here is considered a misuse? I couldn't find any documentation on a case quite like this.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

I would hope for one of these:

1. This works, maybe inefficiently, but it works.
2. This doesn't compile, or it emits a runtime warning hinting me to the right path.
3. This silently fails but there's clear documentation on nested observable state leading me to use scope() instead.

Actual behavior

Clicking the increment and decrement buttons doesn't update the view.

Reproducing project

This is the CaseStudies project from TCA with the 01-GettingStarted-Bindings-Forms sample replaced by the code above. And a few tweaks to make it build under iOS 16.

CaseStudies.zip

The Composable Architecture version information

main

Destination operating system

tested on iOS 16.4 and iOS 18.0

Xcode version information

Version 16.1 (16B40)

Swift Compiler version information

swift-driver version: 1.115 Apple Swift version 6.0.2 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)
Target: arm64-apple-macosx15.0

[stephencelis]

@watt @ObservableState is only meant to be applied at the Feature.State at the moment. While we'd welcome discussion and design to explore supporting it in a nested fashion, we don't currently consider this a bug. As such I'm going to convert it to a discussion for now.

[bioche]

Is this still the case at this time @stephencelis ? I was considering setting my models as @ObservableState to avoid flattening them in the features States but maybe this is not such a good idea ^^

[bioche]

Nevermind I rewatched the video on structural identity that explains the role of the store with the registrar, it makes sense it's only valid when directly in store ^^ I was confused because it works with Swift's Observable but it's on classes.