BindableState changes are not corrected reflected on first appearance of the hosting View

[ylorn]

Describe the bug

• The view appear for the first time;
• In onAppear { ... }, send an action viewAppear;
• In the view's reducer, after receiving the action viewAppear, make some changes to a state's property, which is a BindableState ;
• The changes are successfully applied to the state (the value is changed);
• However, that change is not reflected on the view.

Note:
This only happens on the first time when the view is appeared. After that, the changes made to the BindableState are correctly reflected.

To Reproduce
TextField.zip

Expected behavior
The changes made to the BindableState should be reflected to the view consistently.

Environment

• swift-composable-architecture version: 0.34.0
• Xcode: 13.4 (13F17a)
• Swift: 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)
• OS: iOS 15.5 (19F77)

Additional context

• I want to have a text field to edit the associated string value of a enum case:

  enum Input: Hashable {
      case email(String)
      case id(String)
  
      var content: String {
          get {
              switch self {
              case .email(let string):
                  return string
              case .id(let string):
                  return string
              }
          }
  
          set {
              switch self {
              case .email:
                  self = .email(newValue)
              case .id:
                  self = .id(newValue)
              }
          }
      }
  
      var storageKey: String {
          switch self {
          case .email:
              return "email"
          case .id:
              return "id"
          }
      }
  }

  Basically, I want transform the code above to following:

  

• The state is simplified to have one BindableState property for demo purpose:

  struct DemoState: Equatable {
      @BindableState var input: Input
  }

• The actions are simplified to have just necessary ones for demo purpose:

  enum DemoAction: Equatable, BindableAction {
      case viewAppear
      case load
      case store
      case binding(BindingAction<DemoState>)
  }

• The environment's functionalities are simplified to be just reading/saving a string value for a given key:

  struct DemoEnvironment {
      var storageClient: UserDefaults = .standard
  
      subscript(
          key: String,
          default value: String
      ) -> String {
          get {
              self[key] ?? value
          }
      }
  
      subscript(
          key: String
      ) -> String? {
          get {
              self.storageClient.string(forKey: key)
          }
  
          nonmutating set {
              if let value = newValue {
                  self.storageClient.set(value, forKey: key)
              } else {
                  self.storageClient.removeObject(forKey: key)
              }
          }
      }
  }

• The reducer is designed to handle actions in following ways:

  • When .viewAppear, send a .load action;
  • When .load, fetch the value from the environment for current Input type if there is such value stored previously;
  • When .store, store the content of the TextField to the environment for the current Input type;
  • When the TextField's content is changed, send a .store action;
  • When the segmented Picker is toggled, send a .load action;

  let demoReducer: Reducer<DemoState, DemoAction, DemoEnvironment> = .init { state, action, environment in
      switch action {
      case .viewAppear:
          return .init(value: .load)
  
      case .load:
          let loaded = environment[state.input.storageKey, default: ""]
          return .init(value: .set(\.$input.content, loaded))
  
      case .store:
          environment[state.input.storageKey] = state.input.content
          return .none
  
      case .binding(\.$input.content):
          return .init(value: .store)
  
      case .binding(\.$input):
          return .init(value: .load)
  
      case .binding:
          return .none
      }
  }.binding()

• The view is implemented as follows:

  struct DemoView: View {
      let store: Store<DemoState, DemoAction>
  
      var body: some View {
          WithViewStore(self.store) { viewStore in
              Group {
                  HStack {
                      Text("Input")
                          .font(.headline)
                      Spacer()
                      if viewStore.input.content.isEmpty {
                          Text("Empty")
                      } else {
                          Text("NOT Empty")
                      }
                  }
  
                  VStack(spacing: 16) {
                      Picker(
                          "Input Selection",
                          selection: viewStore.binding(\.$input)
                      ) {
                          Text("Email")
                              .tag(Input.email(viewStore.input.content))
                          Text("ID")
                              .tag(Input.id(viewStore.input.content))
                      }
                      .pickerStyle(.segmented)
  
                      TextField(
                          viewStore.input.storageKey,
                          text: viewStore.binding(\.$input.content)
                      )
                      .autocapitalization(.none)
                      .disableAutocorrection(true)
                      .keyboardType(.emailAddress)
                  }
              }
              .onAppear {
                  viewStore.send(.viewAppear)
              }
          }
      }
  }

• However, if a value of email is stored in the UserDefaults and cold-boot the demo app from a killed state, the view looks like this:
  

• It seems the value is correctly loaded in the state, but not correctly reflected on the view.

Work Around
I figured out 2 workaround:

1. Remove the HStack indicator from the DemoView, somehow this makes the DemoView correctly reflects the DemoState:

       var body: some View {
           WithViewStore(self.store) { viewStore in
               Group {
   -                HStack {
   -                    Text("Input")
   -                        .font(.headline)
   -                    Spacer()
   -                    if viewStore.input.content.isEmpty {
   -                        Text("Empty")
   -                    } else {
   -                        Text("NOT Empty")
   -                    }
   -                }
   
                   VStack(spacing: 16) {
                       Picker(

2. Or: add a delay to the reducer before the .viewAppear action send the .load action, it seems the delay does the trick:

   let demoReducer: Reducer<DemoState, DemoAction, DemoEnvironment> = .init { state, action, environment in
       switch action {
       case .viewAppear:
           return .init(value: .load)
   +            .delay(for: 0.1, scheduler: DispatchQueue.main)
   +            .eraseToEffect()
   
       case .load:

[tgrapperon]

Hello @ylorn!

There is a gotcha with Group: modifiers you apply to it are effectively applied to each child. In your case, you end up sending .viewAppear twice, causing weird race conditions. You can check this by appending .debugActions() to your reducer. The issue will go away if you replace your group by a VStack for example, or limit .onAppear to only one child.

Edit: No need to be ashamed: you can see myself tripping into it a few months ago: #801 …

[mbrandonw]

Yeah, I think @tgrapperon hit the nail on the head! Gonna close out this issue and move it to a discussion. 😃

[ylorn]

a gotcha with Group: modifiers you apply to it are effectively applied to each child.

This is new to me.
I always thought Group is the same as V/HStack, only without any alignment...

It seems Section has the same nature as Group as well, which causes multiple .viewAppear actions.

Thanks and sorry for the fuss, SwiftUI newbie here 😅
@tgrapperon @mbrandonw

[ylorn]

@tgrapperon

In your case, you end up sending .viewAppear twice, causing weird race conditions.

The issue will go away if you replace your group by a VStack for example, or limit .onAppear to only one child.

I tried both replacing the Group with VStack and limit .onApper on one child, the issue did go away, but the .viewAppear still gets sent twice.

Can you teach me the correct way to send the action .viewAppear only once?

[tgrapperon]

But then I would lose the capability of switching different Environment instance?

@ylorn The objective is to keep a handle to your Store instance. Bare properties of SwiftUI views are not reliable for storing information you want to keep around, as you don't really know when your view will be recreated, and the property reset.

One alternative is to use as @State property inside your view or scene to store your Store instance. If you're new to SwiftUI, it could look confusing: you will not use @State for its capacity to invalidate the view's body when it wrapped value change (this is your Store instance, it won't change), but rather because its lifetime is tied to the identity of the view, or in other words, to the "lifetime" of the view. Something you store in @State will be kept around if the view is recreated. Furthermore, its initial value is only evaluated once. It means that you can initialize a View with a Store argument, and store it in a @State:

struct DemoView: View {
  @State var store: Store<DemoState, DemoAction>
  init(store: Store<DemoState, DemoAction>) {
    self.store = store
  }
  …
}

The value will only be assigned the first time, and reused later. If the store instance you provide as argument changes, it will not be assigned to the @State property, as counter-intuitive as it is.

This kind of ownership is similar to what's happening with @StateObject which is a kind of @State @ObservedObject (albeit even less convenient to initialize parametrically). @StateObject are not currently used in TCA.

Please note that you should not do this for every view in your app, but only for the View or Scene that is hosting the root store.

[jshier]

Please note that you should not do this for every view in your app, but only for the View or Scene that is hosting the root store.

This doesn't apply to the root App, does it? It doesn't make sense to me that you'd need it there, as nothing should recreate the App.

[ylorn]

Something you store in @State will be kept around if the view is recreated. Furthermore, its initial value is only evaluated once.

Thanks! This is good to know.

[tgrapperon]

@jshier I agree that if you only have one store instance, top-level, static or App's property should be equivalent.¹

However, in a few cases, you need something that is grained at the WindowGroup level (for example, document-based apps where stores should be independent. In this case, you can either use a dictionary at the App/top-level, or you can use the @State trick on some root-level View if their store's lifetime should be bound to their window's. It can also be useful if you want to perform some additional logic according to some Environment/UIApplicationDelegateAdaptor values: you wouldn't be able to access them and store your root store at the same level without having to mutate the App. It then remains the top-level dictionary route for manual management, or the @State one for automatic management, among other solutions.

However, all of this doesn't really apply to Mocks/UITests which should probably use a dedicated App/target with appropriate Environment values.

Footnotes

1. The original code had a Store instance that was initialized and stored in DemoView. Even if experience shows that SwiftUI is very conservative at invalidating only what's required, I'm not sure about the app's lifetime behavior, and what happens to WindowGroup or its content when the app evolves through various levels of background/active state. The rule I'm following is that body or bare View properties are not a safe place to store things. Maybe I'm overzealous. ↩

[ylorn]

Maybe I'm overzealous.

@tgrapperon
No you are not! I cannot appreciate more! It is hard to come across these issues when learning on my own, but they would be really useful to avoid pitfalls in practice.

Thanks again!