Is it correct to apply @ObservableState to model objects?

[gerfarfel]

In the following example, is it correct to apply @ObservableState to the Person struct?

Without that annotation, state is over-observed in the view, as the view is refreshed when the date field is modified, even though only the name field is referenced in the view. Sorry if I've missed this in the documentation or elsewhere, but I want to make sure I'm not missing something, or heading down the wrong path. Thanks!

import ComposableArchitecture
import SwiftUI

@ObservableState          // <--- IS THIS CORRECT?
struct Person: Equatable {
  var date: Date
  var name: String
}

@Reducer
struct Test {
  @ObservableState
  struct State: Equatable {
    var person: Person = Person(date: Date(), name: "Biff")
  }

  enum Action: Sendable {
    case updateButtonTapped
  }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .updateButtonTapped:
        state.person.date = Date()
        return .none
      }
    }
  }
}

struct TestView: View {
  var store: StoreOf<Test>

  var body: some View {
    let _ = Self._printChanges()
    VStack {
      Text(store.person.name)
      Button {
        store.send(.updateButtonTapped)
      } label: {
        Text("Update")
      }
    }
  }
}

@main
struct TestApp: App {
  var body: some Scene {
    WindowGroup {
      TestView(store: Store(initialState: Test.State()) { Test() })
    }
  }
}

[mbrandonw]

Hi @gerfarfel, observation is only as granular as @ObservableState is applied, and so if you truly need to be super granular with observation then you can apply the macro to a domain type that is not just a reducer state. However, I would start with only applying it to reducer states first and only consider adding it to domain types if the over-observation is truly a problem.

[gerfarfel]

Thanks @mbrandonw. As a follow-on, I've been experimenting with the shared state beta, and it appears that applying @Shared to the person property in my example code also causes over-observation in the view, even with @ObservableState applied to the Person struct. Prior to TCA 1.7, over-observation wasn't really an issue because state was tested for equality. I know you've put a lot of effort into minimizing over-observation with the new observation tools, and I hope you'll continue to focus on that as you finalize the new shared state tools. My app has some views that have fairly heavy rendering overhead, so being able to control when views are refreshed matters. So far, I'm finding that to be quite a bit more challenging with the observation and shared state tools. I'd love to learn more about strategies for mitigating this issue. Thanks again!

[mbrandonw]

Hi @gerfarfel, yeah we have previously considered putting the special observation logic in Shared and for the moment decided against. But it is something we will discuss again.

[gerfarfel]

Fwiw, I think having the observation and shared state tools play as well together as possible would provide a huge amount of value. In my app, shared state is going to be most useful for long-lived objects in the root store (as opposed to something more transient, like a sign-in workflow). Ideally, there wouldn't be a trade-off between adopting shared state and having access to all of the benefits of the observation tools.