Ability to commit or cancel child state

[prasannag]

In the Todos example, I'm trying to display the todo name in a modal. From the modal, I would like to either commit changes made or cancel the changes. Using the following code, any changes to Todo in TodoEditView is immediately applied to the parent with no opportunity to cancel. How would I model this behaviour?

struct TodoEditState: Equatable {
  var todo: Todo
}

enum TodoEditAction: Equatable {
  case textChanged(String)
}

let todoEditReducer = Reducer<TodoEditState, TodoEditAction, TodoEnvironment> { state, action, environment in
  switch action {
  case .textChanged(let value):
    state.todo.description = value
    return .none
  }
}

struct TodoEditView: View {
  var store: Store<TodoEditState, TodoEditAction>
    var body: some View {
      WithViewStore(store) { viewStore in
        TextField(
          "Description",
          text: viewStore.binding(
            get: \.todo.description,
            send: TodoEditAction.textChanged
          )
        )
      }
    }
}

And here is the updated Todo

struct Todo: Equatable, Identifiable {
  var description = ""
  let id: UUID
  var isComplete = false
  
  var isPresented = false
  
  var todoEditState: TodoEditState {
    get { .init(todo: self) }
    set { self = newValue.todo }
  }
}

enum TodoAction: Equatable {
  case checkBoxToggled
  case textFieldChanged(String)
  case setSheet(Bool)
  case todoEdit(TodoEditAction)
  case presentEdit
}

[tgrapperon]

Hey @prasannag! This is a general domain modeling issue that is not specific to TCA. I would probably create a dedicated scratchpad editedTodo: TodoState? property that would be the basis of the "editing" view (and maybe your modal), and I would commit the changes on a "save" action, or when the editedTodo states goes nil, or on onDisappear (which can be a little too late and will likely be visible). You may need to wrap editedTodo into some larger state to host additional editing-related properties. This approach is not new: This is how you generally edit an entity in CoreData, by creating a temporary NSManagedObjectContext that comes with its own UndoManager, and simply discard it with all the changes if you decide to not persist them.

Another approach would be to create some "Resettable" higher-order feature in the same spirit as the simple undoable one that I've already seen around here (but I can't find it back right now). But this is a little more work, and this kind of approach will still commit each change before resetting, which can be problematic in some contexts. At worse, you can probably augment this higher feature to make it behave like the first approach, with dedicated storage and a .save action in addition to your .reset one.

An .editable() generic and reusable higher-order feature like .binding(), with proper undo management and callbacks may be possible, but it would require some work if you want to make it interact nicely with UndoManagers at the system level. I think there is a third party library partially bridging with them, but I can't find them back neither.

So, the first, ad hoc solution, seems the simplest to implement. If you encounter many domains with this characteristic, you may think about abstracting it into something more reusable.