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

[beaneyios]

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?

[JackYoustra]

State sharing can be tricky in TCA! Do not fret, you'll soon get the hang of it :)

The construct you're looking for is forEach, where you swap out your todos array with an IdentifiedArray of your TodoListFeature.State and put in the Todo struct inside the TodoListFeature.State.

See:

swift-composable-architecture/Examples/Todos/Todos/Todos.swift

Line 102 in 8330f53

.forEach(\.todos, action: /Action.todo(id:action:)) {

I also encourage you to look at the case studies. One example is a mini Todos app! It should contain the best practices, feel free to let me know any questions you may have.

[beaneyios]

Thanks for the quick response! This answers my question directly thank you.

I have a followup question if that's okay?

Your answer is applicable to a parent/child reducer where the parent is a list and the child handles items in that list (which is exactly what I asked for in my example, of course) but what about situations where the state that needs sharing is not list-based.

Imagine this (admittedly silly) example where I now introduce the concept of a user object, managed by its own reducer.

struct UserFeature: ReducerProtocol {
    
   struct State {
        var tickedItemsCount: Int
   }

   enum Action {
       case itemTicked
   }

   func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    
       switch action {
       case .itemTicked:
            state.tickedItemsCount += 1
       }
   }
}

And then I'd add an action to TodoListFeature called tickItem(id: String) to actually interact with the server and do the "ticking", and once that's done inside the TodoListFeature reducer, I'd want to update the state that belongs to UserFeature.

I could be wrong, but I feel like that's an example where a different approach would be needed right?

I'll take a look through the examples to see if there's anything, but I do appreciate your input.

[beaneyios]

Following up on this - I found a good example of where you can delegate from a child reducer to a parent reducer in a more generic way in the voice memos example https://github.com/pointfreeco/swift-composable-architecture/blob/8330f534c60fb10dcf390a06ad934c8916491b69/Examples/VoiceMemos/VoiceMemos/VoiceMemos.swift

That works well if the state I ultimately want to update is in the parent reducer.

But what if I want to go from ChildReducerA up to ParentReducer and then propagate that new state down to ChildReducerB? I don't see anything in the examples of that nature.

[mariob]

You could take a look at using Shared State, check the use case example: [https://github.com/pointfreeco/swift-composable-architecture/blob/8330f534c60fb10dcf390a06ad934c8916491b69/Examples/CaseStudies/SwiftUICaseStudies/01-GettingStarted-SharedState.swift](https://github.com/pointfreeco/swift-composable-architecture/blob/8330f534c60fb10dcf390a06ad934c8916491b69/Examples/CaseStudies/SwiftUICaseStudies/01-GettingStarted-SharedState.swift. Maybe that can solve the problem?

I'm actually trying this myself now for sharing state between three tabs and it works really nice. When something changes the shared states all the reducers will immediately get the update.

You could also just send an action to child-b from the parent when you receive the delegate action from child-a in the parent. Would be interesting to hear what others thinks about this.

[beaneyios]

Both of these seem like good suggestions to me. I suspect each will have its own use-case actually since SharedState relies on ReducerA modifying the state in a way that's acceptable to ReducerB/maybe even duplicating logic that exists already in ReducerB (the example you gave doesn't do that, but it's easy to imagine that happening in the course of building an app).

This community is really responsive/helpful btw folks - thanks a lot for the quick answers.