Can I embed a child domain into a generic container domain.

[danthorpe]

Let's say that I have a form for the user to fill in. At the top level, the form is made up of N different sub-forms which are all distinct. However, at the parent level, and each child level I want the ability to apply, cancel and reset any edits. So, I could model this as a parent domain with 5 child domains.

I'm just trying to figure out how to apply, cancel or reset any changes in the child domains without repeating a bunch of boiler plate.

I was thinking of doing something like...

struct EditableState<State> {
  var original: State
  var reset: State
  var working: State
}

enum EditableAction<Action> {
  case wrapped(Action)
  case reset, cancel, apply
}

I could then extend Reducer to return an "editable" Reducer which would combine the receiver to work on the working State, and then update the original with the working state to perform apply and update the working with the reset state to perform reset. e.g.

typealias EditableReducer<State, Action, Environment> = Reducer<EditableState<State>, EditableAction<Action>, Environment>
extension Reducer {
  func editable() -> EditableReducer {
    .combine(
      self
        .pullback(
          state: \.working,
          action: /EditableAction<Action>.wrapped,
          environment: { _ in () }
        ),

        EditableReducer { state, action, _ in 
          switch action {
          case .wrapped:
            return .none
          case .reset:
            state.working = state.reset
          case .apply:
            state.original = state.working
          case .cancel:
            return .none
          }
        }
    )
  }
}

This works fine for a single TCA domain. The challenge comes when I want to embed N child domains into a parent, so that the parent can reset/apply changes in all children, yet each child is can also do reset/apply independently, and update the parent state.

The naive approach which I've taken to start with is as follows...

struct ChildState {
  var foo: String
}
enum ChildAction {
  case bar
}
struct FormState {
  var child: EditableState<ChildState>
}
enum FormAction {
  case child(EditableAction<ChildAction>)
}

The problem with this approach, is that by wrapping the child domain in EditableState and EditableAction inside of the parent domain - it makes it much much harder to scope the store (although it is possible).

A far better approach, I think, would be to compose the child state inside the form state normally, and only when showing the UI to edit the form (whether it be child or parent) do we compose inside the Editable domains.

So, in other words, I want to scope the parent store to get the child store - but then, sort of embed this child into a reusable container domain for editing. All the while updating the parent store...

I've searched high and low, and it seems like something like this would be pretty common requirement, so I'm wondering if I'm missing something, or if there is another, better way to achieve what I want.

p.s. Obviously, I could also put reset/apply into each domain individually - but these seems like lots of repetitive boiler plate, and surely there is a better way....

---

I suppose another idea, to solve this specific problem, would be to create a system similar to @BindingState, BindableAction and BindingAction. Because the EditableState above, could become a property wrapper, because the original is basically a wrappedValue and the editingValue is a projectedValue. We could pass in a value to represent resetting the state too. e.g.

struct ParentState: Equatable {
  @EditableAction(reset: .init()) var child = ChildState()
}
enum ParentAction: EditableAction, Equatable {
  case editing(EditingAction<ParentState>)
}

Perhaps this would then allow us to create functions on ViewStore for save and reset which would mutate the state in the same way that the binding(_:) works.

Also, of course, this would just be a solution for this specific use-case regarding editing child states, which might have limited utility outside of my use-case.