@BindableState shared between sibling States

[patch-benjamin]

So I’m fairly new to TCA and we committed to using it in our Greenfield app right after you released the Reducer Protocol update, so that’s the context I’m currently in. I love the reducer protocol update btw. It’s beautiful.
The issue I'm running into is how to share Bindable data between sibling States. From what I understand State hierarchies pretty much mirror View hierarchies, meaning the top-level State will essentially contain all the data for the app (nested in sub-state objects). If I'm off there, please correct me.
For SwiftUI Views we have things like @State and @Binding to allow data to be shared between subviews. In TCA we currently only have @BindableState (essentially the Reducer.State's version of @State), but no way to bind sub-States to that value (something akin to @Binding).
For (a contrived) example, the following is possible in Vanilla SwiftUI using @State and @binding but I can't figure out how to do this using conceptually with TCA:

@State var username = “" // @BindableState in a TCA `Store`
Var body: some View {
	VStack {
		EditUsernameView($username) // This would use a `.scope` in TCA, but how do I make it so the scoped data references the same BindableState on the current State?
		FancyEditUserNameView($username)
	}
}

In the above code my username State variable is the source of truth for two child views. If either of those chid views edit the username, the edit will propagate through the view hierarchy and reflect the changes to any other views that are bound to the username state.
Do you have a preferred approach for this kind of situation with TCA? I can make it work by having an @Binding on my "ChildState", but it’s not super ideal for a few reasons (see comments in the example at the bottom). My coworker created a Reducer-modifier that syncs a two values between two states, but I don’t love the bi-directional state mutations happening with that approach — there are two separate instances of conceptually the same object, and we just sync them... I’d prefer a more reference-like approach where there is a single source of truth.
This seems like a fairly common situation to run into but I'm having a hard time finding an example in the wild that supports this... Maybe it's just unaccounted for with the newish @BindableState -- for instance if you don't use an BindableState/Action/Reducer, you could just intercept the Child-Action sent (.updateUsername(String)) in the Parent Reducer and sync all the sharedStates that way. Granted, this is not ideal, but doable from my understanding:

case .child1Action(let action): 
  switch action { 
  case .updateUsername(let username): 
    self.username = username 
    state.child2.username = username
    state.child3.username = username
    return .none 
  default: return .none
  }
...
// repeat for Self.Action, Child2.Action, and Child3.Action

So, this is my best attempt at something like this so far -- just passing in a Binding to the child-State when scoping the store down. Do you have an example of a better way of accomplishing this?

// MARK: - Parent
// MARK: Reducer

public struct Parent: ReducerProtocol {
    public struct State: Equatable {
        @BindableState var name: String
        var childState: Child.PartialState
    }

    public enum Action: BindableAction, Equatable {
        case binding(BindingAction<State>)
        case childAction(Child.Action)
    }

    public var body: some ReducerProtocol<State, Action> {
        BindingReducer()
        Reduce { state, action in
            return .none
        }
    }
}

// MARK: View

struct ParentIntercepterView: View {
    var store: StoreOf<Parent>

    var body: some View {
        WithViewStore(store) { viewStore in
            VStack {
                TextField("name", text: viewStore.binding(\.$name))
                ChildView(store: store.scope(state: { parentState in
                    // NOTE: Doable, but not super intuitive.
                    // NOTE: Can I reference `viewStore` in here without consequences..? Maybe need a weak reference to it, which would also be unintuitive and non-ideal.
                    Child.State(name: viewStore.binding(\.$name), state: parentState.childState)
                }, action: Parent.Action.childAction))
                // For the sake of simplicity I'm reusing same the ChildView/Reducer as a sibling, but conceptually these would be different.
                ChildView(store: store.scope(state: { parentState in
                    Child.State(name: viewStore.binding(\.$name), state: parentState.childState)
                }, action: Parent.Action.childAction))
            }
        }
    }
}


// MARK: - Child
// MARK: Reducer

public struct Child: ReducerProtocol {
    public struct State: Equatable {

        // NOTE: This is annoying :(
        public static func == (lhs: Child.State, rhs: Child.State) -> Bool {
            lhs.name == rhs.name
        }

        @Binding var name: String
        var state: PartialState
    }
    // NOTE: this is not ideal.
    public struct PartialState: Equatable {
        // additional, non-binding data needed by this Reducer
    }


    public enum Action: Equatable { }

    public func reduce(into state: inout State, action: Action) -> ComposableArchitecture.Effect<Action, Never> { }
}

// MARK: View

struct ChildView: View {
    var store: StoreOf<Child>

    var body: some View {
        WithViewStore(store) { viewStore in
            TextField("name", text: viewStore.$name)
        }
    }
}

[ibrahimkteish]

I dont know if I fully understand your question, I was able to come up with the following:

The main idea was just to treat the sub state as computed property and relay the changes in the set {}

// MARK: - Parent
// MARK: Reducer

public struct Parent: ReducerProtocol {
  public struct State: Equatable {
    @BindableState var name: String

    var childState: Child.State {
      set {
        self.name = newValue.name
      }
      get {
        .init(self.name)
      }
    }
  }

  public enum Action: BindableAction, Equatable {
    case binding(BindingAction<State>)
    case childAction(Child.Action)
  }

  public var body: some ReducerProtocol<State, Action> {
    BindingReducer()

    Scope(state: \.childState, action: /Action.childAction) {
      Child()
    }

    Reduce { state, action in

      return .none
    }
  }
}

// MARK: View

struct ParentIntercepterView: View {
  var store: StoreOf<Parent>

  var body: some View {
    WithViewStore(store) { viewStore in
      VStack {
        TextField("name", text: viewStore.binding(\.$name))
        ChildView(store: store.scope(state: \.childState, action: Parent.Action.childAction))
        ChildView(store: store.scope(state: \.childState, action: Parent.Action.childAction))
      }
    }
  }
}


// MARK: - Child
// MARK: Reducer

public struct Child: ReducerProtocol {
  public struct State: Equatable {

    @BindableState
    var name: String = ""

    init(_ name: String = "") {
      self.name = name
    }
  }

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

  public var body: some ReducerProtocol<State, Action> {
    BindingReducer()
    Reduce { state, action in
      switch action {
        case .binding(\.$name):
          return .none
        case .binding:
          return .none
      }
    }
  }
}

// MARK: View

struct ChildView: View {
  var store: StoreOf<Child>

  var body: some View {
    WithViewStore(store) { viewStore in
      TextField(
        "name",
        text: viewStore.binding(\.$name)
      )
    }
  }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
      ParentIntercepterView(
        store: .init(
          initialState: .init(
            name: "name"
          ),
          reducer: Parent()
        )
      )
    }
}

[patch-benjamin]

Thanks for the quick reply @ibrahimkteish!
Sorry, I should have been more explicit in the code I shared. I was trying to keep it shorter for readability... but I suppose longer, more explicit questions are better than shorter, more vague questions.
So to clarify, the scenario I'm referring to is that 2 subStates (somewhere down the State tree, not necessarily immediate child-states) have several variables on them including a shared, bindable String.
So a State breakdown like the below diagram shows would have been clearer on the scenario I'm curious about.
_A
| |
B1 B2
| | |
C1 C2 C3 - @BindableState var username
|
D1 - @BindableState var username

Each letter above is a State. So in addition to it's own specific variables, State-A has two child-states: State-B1 and State-B2, both of which have their own slew of personal variables, one of which is the other sub-states shown in the diagram.
The question I had was: how do I get C3.username to sync with D1.username?

[mbrandonw]

Hi @patch-benjamin, the approach mentioned by @ibrahimkteish above can work. It's a little bit of boilerplate to maintain the computed property, but it does work. We also have a case study to show this style off.

There are a few other approaches.

First off, if we look at the vanilla SwiftUI example you shared:

@State var username = ""
var body: some View {
  VStack {
    EditUsernameView($username)
    FancyEditUserNameView($username)
  }
}

If one of the examples in your app really is this simple, then you should know you can still use bindings to have a single source of truth but hand off little slices of that source of truth:

@ObservedObject var viewStore: ViewStoreOf<Feature>
var body: some View {
  VStack {
    EditUsernameView(viewStore.binding(get: \.username, send: Action.setUserName))
    FancyEditUserNameView(viewStore.binding(get: \.username, send: Action.setUserName))
  }
}

That works just like vanilla SwiftUI.

The approaches above try to keep everything in state, which has its pros, but also cons (like the boilerplate). There is a 3rd approach that is a lot different from the above two.

If the "shared state" is truly ubiquitous and global, then it may be best kept in a dependency. At that point it's not too unlike a database or user defaults. This dependency could expose synchronous access to the underlying data, and provide effectual endpoints for setting and subscribing to changes in the reducer.

[patch-benjamin]

Super interesting! It's funny when I was writing the question I was thinking, Binding is a decent comparison for what I want, but I would also love capabilities more akin to the Environment. I did think of @Dependency, but didn't think it would work for this situation since only the Reducer has access to it (and it only works inside the reduce/body function).
I'll have to check out how a user-defaults dependency works in TCA, but I'm pretty confident this will answer my question! 🎉 Thanks @mbrandonw

[patch-benjamin]

@mbrandonw do you have an example of this I could leverage by chance?

I'm running into issues conceptualizing this since the State cannot be initialized from Reducer.body/Reducer.reduce(into:action:) and the injected Dependency is only accessible in that Reducer variable/function.

You could make the variable on State be optional, but then your State would be invalid/inaccurate until reduce is called on your Reducer (or in other words until the first Action is sent). This would make State somewhat fragile and unintuitive to get it into a "proper" state (an unknown requirement of having an Action sent to the Reducer to "finish" initializing the State).

If reduce was called on init (akin to many publishers always publishing on subscription) that would solve this issue, but that's not how it currently works as far as I understand it.

Am I thinking about this wrong?
Or do you have a workaround for the issue above?

Thanks in advance!