TCA - send an event from one reducer to another/modify the state of a different store

[beaneymidnite]

I'm new to TCA so I may have the entirely wrong approach here, so apologies if so I and I would appreciate getting pointed in the right direction. It's a little bit tricky to find resources for this since I've adopted the new ReducerProtocol approach to TCA and the vast majority of the tutorials/documentation I can find uses the old approach.

Essentially - imagine I have two reducers, TodoListFeature and TodoItemFeature. The former displays a list of todo items, and the latter displays a single todo item, and allows editing of its information (e.g. title).

So TodoListFeature might look like this:

struct TodoListFeature: ReducerProtocol {
    
   struct State {
      var todoItems: [TodoItem]
   }

   enum Action {
      case onAppear
      case dataLoaded(Result<[TodoItem], Error>)
   }

   func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    
       switch action {
       case .onAppear:
           // perform async action to fetch todos, then dispatch .dataLoaded
       case .dataLoaded(let result):
           // update state
       }
   }
}

and then TodoItemFeature something like this:

struct TodoItemFeature: ReducerProtocol {
    
   struct State {
      var saveError: Error?
   }

   enum Action {
      case updatedItem(TodoItem)
   }

   func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    
       switch action {
       case .updateItem(let item):
           // perform async action to update the todo... but then what?
       }
   }
}

So this is the question - see the "...but then what" comment? Essentially I now want to take that updated item, and update my state in TodoListFeature - in other words, I'd like to update the list.

I've read about composition, but this just seems to be arbitrarily grouping together features into a single store and then scoping that single store depending on the view we're in. How do I get the combined reducers to talk to one another? I considered adding some kind of delegation pattern, where TodoListFeature becomes a delegate of TodoItemFeature, but this feels like it's working against the pattern and that there is probably something in the library that I'm missing.

I have a pal who is versed in Redux and he says I should just have one reducer called TodosReducer that combines both of these reducers. That may be the case here - but I don't believe for a second that a more complex app won't have side effects in ReducerA that ought to update state in ReducerB. How do we deal with that?

[tgrapperon]

Hey @beaneymidnite.

but then what?

Nothing! If you embrace composition. In your case, the TodoItemFeature reducer will not even run, as it is not installed as a (collection of) child domain of TodoListFeature. To achieve this, you need to:

• Make TodoItemFeature.State Identifiable (and also probably store a TodoItem value)
• Replace your Array of TodoItem by an IdentifiableArrayOf<TodoItemFeature.State>. As items can move, we need to have a type that allow to track them. This is required for the next steps.
• Add a case todoItems(TodoItemFeature.Action) in your TodoListFeature.Action
• Replace your reduce function by body:

var body: some ReducerProtocolOf<TodoListFeature> {
  Reduce<State, Action> { state, action in
    // the content of your `reduce` function
  }
  .forEach(\.todoItems, action: /Action.todoItems) {
    TodoItemFeature()
  }
}

Now, each action received by a TodoItemFeature will run TodoItemFeature and then TodoListFeature's Reduce, and state will be correctly propagate.

Please note that you'll also need a way to update your todoItem value in TodoItemFeature after your async work, so you should probably add an action .write(TodoItem) there (update is already taken).

To use it in a View, you'll need ForEachStore. I strongly encourage you to look at the case studies and the Todos example from the repo, where all the operations above are performed.

I should just have one reducer called TodosReducer that combines both of these reducers

The TodoListFeature with body as I wrote is already combining both of them. Having them as sibling is technically possible, but in your case, the List domain is clearly a parent of the Item domain, so you'll definitely have more success by nesting them as I suggested. But nothing prevents you to embed the List domain itself in whatever parent it needs to be, etc.