Splitting Dependant Reducers - events

Question

My question is regarding how to organize my reducers.
Lets say I have a state shape like this:
resources: [
{
id: 1,
name: "John",
/* ... 100 more properties ... */
},
{
id: 1,
name: "Daniel",
/* ... 100 more properties ... */
},
]
events: {
planned: [
{
resourceId: 1,
name: "Concert with Adele",
/* ... 100 more properties ... */
}
]
}
As a start, let's say we have a single Reducer in place. The business logic is as such:
One can add and remove a resource at any time.
If there's an event without a resource, the first resource will be added to the event.
If there's an event with a resource and the resource is removed and there are no other resources, the resourceId will be unset.
If there's an event with a resource and the resource is removed and there are other resources, the resourceId will be set to the first of the remaining resources.
There is a lot of logic that is in place to handle the "resources" branch of the state tree, and simultaneously there's a lot of logic in place to handle the "events" part of the state tree.
Points 2,3 and 4 introduce a dependency between "resources" and "events", that I'm trying to resolve in the best possible way.
Naive solution
The naive solution would be to have one reducer to handle all of the actions. In that way, when a resource is removed, we can simply remove the resource, check if there are any other resources left and then update the events accordingly. However, keeping logic for 'resources' and 'events' together, just because of this feels not nice.
Maintain own list
Another alternative would be to split handling of Resources and Events to two different reducers. In the Events part of the state tree, we could keep a list of available resourceIds, so that we know how to update our events. We can still listen to the same events as the Resource reducer, but only saving the relevant data. Something like
resources: [
{
id: 1,
name: "John",
/* ... 100 more properties ... */
},
{
id: 2,
name: "Daniel",
/* ... 100 more properties ... */
},
]
events: {
resourceIds: [1,2], /* ADDED: Keeping track of available resources */
planned: [
{
resourceId: 1,
name: "Concert with Adele",
/* ... 100 more properties ... */
}
]
}
Proxy actions
A third option would be to create a listener (with for instance redux-saga) for REMOVE_RESOURCE actions, and then trigger another action UPDATE_DEFAULT_RESOURCE_ID which would contain the current default resource id.
Any thoughts on what the right approach here is?

Answer 1

I personally love to split my code in ducks and use a normalized state as you stated in your option 2. Whenever I need to do some complex logic involving two or more reducers, I use redux-saga as you mentioned in your third option.
Doing this way I keep the "inter reducers" logic separate and more easily testable via sagas. Also, you can't ending up with a duck circle.
In general, when you see a circle dependency it's often a strong signal of a poor design.

Answer 2

Chain reducers so that an action that updates your events uses the resources reducer, which separates the concerns of the two while maintaining the dependency.
event_reducer(state, action) {
switch(action.type) {
case 'REMOVE_RESOURCE_FROM_EVENT':
return {...state, resource_id: resource_reducer(null, action)}
}
}
resource_reducer(state, action) {
switch (action.type) {
case 'REMOVE_RESOURCE_FROM_EVENT':
let id = null;
if (resources.length > 0) {
id = resources[0].id;
resources = resources.slice(1);
}
return id;
}
}