A concern on combineReducer, when an action is related to multiple reducers

[tiye]

I'm working on a chat app built with React.js and Flux. As I read the docs of Redux the combineReducer function appears strange to me. For example:

There are three stores called messageStore, unreadStore, threadStore. And there's and action called NEW_MESSAGE. All three stores will update on new messages. In Redux, the stores are reducers combined with combineReducer like:

message = (state=[], action) ->
  switch action.type
    when NEW_MESSAGE
      state # new state
unread = (state=[], action) ->
  switch action.type
    when NEW_MESSAGE
      state # new state
thread = (state=[], action) ->
  switch action.type
    when NEW_MESSAGE
      state # new state

combineReducer {message, unread, thread}

It appears to me the in such cases, splitting reducers is not making my life easier. However a giant store built with immutable-js maybe a better solution for this. Like:

initialState = Immutable.fromJS
  message: []
  unread: []
  thread: []

allStore = (store=initialState, action) ->
  switch action.type
    when NEW_MESSAGE
        initialState
        .updateIn ['message'], (messages) -> messages # updated
        .updateIn ['urnead'], (urneads) -> unreads # updated
        .updateIn ['thread'], (threads) -> threads # updated

[gaearon]

Can you elaborate why you think combineReducers isn't helpful in this case? Indeed, for database-like state, you often want a single reducer (and then other reducers for UI state, for example, selected item, etc).

See also:

https://github.com/rackt/redux/tree/master/examples/real-world/reducers
https://github.com/rackt/redux/blob/master/examples/async/reducers

for inspiration.

[tiye]

The first exmple you pointed about is similar to my case, requestType is handled in both reducers.
https://github.com/rackt/redux/blob/master/examples/real-world/reducers/paginate.js#L28

Splitting reducers makes it easier for maintaining when two reducers are seperated from earch others. But when they are handing to the same actions, it leads to:

• for such an action, I have to maintain it in several reducers(or files after my app grows). In our current codebase we already saw 5 stores handling a same action, it's a bit hard to maintain.
• in some cases, one reducer may depend on data from another(like moving a message from unread to message, or even promote a message as a new thread from message to thread). So I may need to get data from another reducer now.

I don't see a nice solution for these two problems. Actually I'm not totally sure about these two problems, they are like tradeoffs.

[gaearon]

for such an action, I have to maintain it in several reducers(or files after my app grows). In our current codebase we already saw 5 stores handling a same action, it's a bit hard to maintain.

Whether this is good or bad depends on your app. In my experience having many stores (or Redux reducers) handling the same action is actually very convenient because it divides responsibilities, and also lets people work on feature branches without colliding with the rest of the team. In my experience it's easier to maintain unrelated mutations separately than one giant mutation.

But you're right there are cases where this doesn't work too well. I'd say they are often symptoms of a suboptimal state model. For example,

in some cases, one reducer may depend on data from another(like moving a message from unread to message, or even promote a message as a new thread from message to thread)

is a symptom of a problem. If you have to move stuff inside your state a lot, maybe the state shape needs to be more normalized. Instead of { readMessages, unreadMessages } you can have { messagesById, threadsById, messageIdsByThreadIds }. Message read? Fine, toggle state.messagesById[id].isRead. Want to read messages for a thread? Grab state.threadsById[threadId].messageIds, then messageIds.map(id => state.messagesById[id]).

When data is normalized, you don't really need to copy items from one array to another array. Most of the times you'd be flipping flags or adding/removing/associating/disassociating IDs.

[tiye]

I'd like to try that.

[tiye]

I just wrote a demo page to try redux. I think combineReducer brought quite some complexity to me. And all the examples in the repo are using combineReducer, is there still chance I can use a single immutable data object as the model, rather than an JavaScript object that contains my data?

[gaearon]

@jiyinyiyong I'm really not sure what complexity you are talking about, but feel free to not use combineReducers. It's just a helper. Check out a similar helper that uses Immutable instead. Or write your own of course.

[jokeyrhyme]

I wrote my own combineReducers() helper mostly to support Immutable.js, but it can take additional reducers that treated like root reducers:
https://github.com/jokeyrhyme/wow-healer-bootcamp/blob/master/utils/combineReducers.js

The first argument matches the shape of your state and passes the top-level sub-states to the matching sub-reducers that you provide. This is more or less the same as the official version.

However, it is optional to add zero or more additional arguments, these are treated like other root reducers. These reducers are passed the complete state. This allows actions to be dispatched in ways that require more access than the recommended sub-reducer pattern.

It's obviously not a great idea to abuse this, but I've found the odd case where it's nice to have multiple sub-reducers as well as multiple root reducers.

Perhaps instead of adding multiple root reducers, a middle step could be using the additional arguments to define sub-reducers that need broader access (still less than total access). For example:

function a (state, action) { /* only sees within a */ return state; }
function b (state, action) { /* only sees within b */ return state; }
function c (state, action) { /* only sees within c */ return state; }

function ab (state, action) { /* partial state containing a and b */ return state; }
function bc (state, action) { /* partial state containing b and c */ return state; }

let rootReducer = combineReducers(
  { a, b, c },
  [ 'a', 'b', ab ],
  [ 'b', 'c', bc ]
);

Is it worth submitting a PR for partial reducers and additional root reducers? Is this a horrible idea, or is this something that could be useful to enough other people?

[tiye]

I feel more like to learn how halogen and elm is dealing with these problems. JavaScript is mixed of several progammig diagrams and leading us to many ways. I'm now confused which is the right one of FRP and unidirectional data flow.

[rhys-vdw]

I have found this to be a point of confusion for me also. Just posting my use case/solution here.

I have three subreducers that handle an array of three different resource types (clients, projects, jobs). When I delete a client (REMOVE_CLIENT), all related projects and jobs must be deleted. Jobs are related to clients through a project, so the jobs reducer must have access to the projects to do the join logic. The jobs reducer must get a list of all project IDs that belongs to the client being deleted, and then remove any matching job from the store.

I got around this issue with the following middleware:

export default store => next => action => {
  next({ ...action, getState: store.getState });
}

So that every action has access to the root store via action.getState().

[pollen8]

@rhys-vdw thanks for that! A really helpful middleware :)

[raphaelokon]

@rhys-vdw Thanks for this – seems like a nice solution. How do you handle edge cases/referential integrity, e.g. when an entity is shared by two (or more) other entities or pointing to a non-existing record during deleting. Just keen to hear your thoughts on this.
@gaearon Is there a documented way in Redux how to solve this kind of referential integrity problem of normalised entities?

[gaearon]

There is no specific way. I would imagine that one can automate this by defining a schema and generating reducers based on this schema. They would then “know” how to collect “garbage” when things are deleted. However this is all very hand wavy and requires implementation effort :-). Personally I don’t think deleting happens often enough to warrant real cleanup. I would usually flip a status field on the model and make sure to not display deleted items when selecting them. Or, of course, you can refresh on delete if it is not a common operation.

[raphaelokon]

@gaearon Cheers for the super fast reply. Yeah … I think one has the same effort in dealing with referential integrity when using references with document-based DBs like Mongo. I think it is worth either to have a pure state without any garbage entities floating around. Not sure if those ghost entries could ever trip you up especially when you have a lot of CRUD ops on your state.

However I also think it would be ace if Redux had support for both – normalised and embedded entities. And one could pick a strategy that fits for purpose. But I guess for embedded entities one must use nested reducers which is an anti-pattern according the Redux docs.