Building an Undo Redo mechanism for TCA App

[shannoga]

Hi

We're developing an Editable Canvas feature in our app using The Composable Architecture (TCA), where users can interact with the canvas in various ways (e.g., adding images, text, stickers, or deleting elements). Each user action triggers a reducer; while some actions are straightforward and executed in a single step, others depend on side effects such as fetching UI data from a server or retrieving assets and fonts.

We aim to implement an Undo/Redo mechanism to enhance user experience. Our initial strategy involves saving a snapshot of the canvas state after every user action, allowing us to restore the state for Undo/Redo functionality. To avoid relying on developers to manually call a save action after each state change—which could lead to oversight and data loss in our Undo/Redo system—we've designed a top-level reducer that automatically creates a state snapshot after every action is processed.

However, we've encountered a challenge in determining when a user-initiated state change, especially those involving side effects, is fully completed. For instance, adjusting an element's position on the canvas is straightforward: we execute an action that updates the state, and then we can immediately capture a snapshot. But when selecting a new layout, which involves fetching layout data from a server as a side effect, our system inadvertently captures two snapshots: one before the side effect is resolved and another after, unnecessarily duplicating state changes related to a single user action.

In TCA, when writing tests, there's a mechanism to ensure that all side effects or actions related to an initial user action are accounted for. Is there a similar approach or another strategy we can adopt to consolidate related state changes into a single snapshot for our Undo/Redo feature?

Thank you for your assistance,
Shani

[shannoga]

Anyone? Impossible is also an helpful answer.
Thanks

[mbrandonw]

Hi @shannoga, it's not impossible, but it's a very difficult problem that highly depends on the context of the app.

Have you see the onChange reducer operator? This allows you to check if a piece of state changes after the reducer processes an action. It seems like you would want to snapshot with that, rather than snapshotting for every single action.

[shannoga]

Thanks for the answer.
My issue is that I want to snapshot the state after all the actions that are related to a single user action are completed, including side effects action. So, for example - if the user taps on a button that loads data async, I would like the snapshot the changes only after the side effect and possible other related side effects are completed.
Is onChange called only after a set of changes is completed?

Thanks

[mbrandonw]

Is onChange called only after a set of changes is completed?

No, but also "set of changes" isn't a well-defined, generic term. It highly depends on your context of what constitutes a fundamental change to the data.

And so for that reason, I think another option is to compose in another reducer where you explicitly switch on each action to decide whether or not to snapshot:

var body: some ReducerOf<Self> {
  // Feature's core logic

  Reduce { state, action in 
    switch action {
    case .actionToSnapshot1, 
         .actionToSnapshot2, 
         .actionToSnapshot3:
      // do the snapshot

    case .actionToIgnore1,
         .actionToIgnore2,
         .actionToIgnore3:
      // No snapshot
      return .none
    }
  }
}

And thanks to exhaustive switching on enums you will be notified when a new action is added and you will need to decide whether to snapshot in that case or not.

[shannoga]

Thanks again for your time @mbrandonw
Sorry if I failed to explain myself again.
We know that this specific reducer handles only actions that their changes we want to snapshot.
A set of changes in our case is all the changes caused by a single user action.
for example -

1. The user makes a change in the UI - (selects a new layout for a pre designed document).
2. We send this action to the reducer.
3. The reducer calls a client that fetches the new layout from the backend.
4. After the layout is fetched, we send a new action with the layout data.
5. We then modify the layout state to the new layout structure.
6. Lets assume for this example that we call an async a service that transfer the user text and images to the new layout
7. When the final layout with the transferred user data is ready we send another action the will update the final layout state.

In that case we want to snapshot the state after the final data is updated. and we will be happy to avoid manually send a snapshot action where needed as this is fragile in our 20 iOS developers team. They can forget adding it, or worse, add it at the end of an action which is final in one flow but not for a different flow.

Thanks for you patient and help
Shani

[mbrandonw]

Hi @shannoga, I'm sorry but I do not think there is any magical solution to this. The logic guiding when a snapshot should and should not be made appears to be quite subtle and nuanced, and so it seems like no matter what you need to do work to determine when it is appropriate to snapshot.