Best practice for updating dependent state across different branches of the state tree?

[jeloi]

In the Reducer docs it says:

Sometimes state fields depend on one another and more consideration is required, but in our case we can easily split updating todos into a separate function..

I'd like to know how to handle that specific use case. To give an example, say I have a form with multiple data fields. I have another component elsewhere that should react to changes in form, e.g change state based on whether the form data is valid, or compute values from different inputs to the form and display them.

While I believe I can have different reducers (which handle different slices of the state tree) listen to the same action and update themselves, the "reactive" state would not have access to the other branches of the state tree that it needs in order to compute itself.

One solution I've thought of is to have the "reacting" process happen by using subscribe to listen to changes in the state tree, compute whether or not a relevant change was made, then dispatch a new action to update the dependent fields. However, this publishing blast might have to become very generic, so that all reducers that care about it will be able to use the payload it comes with.

I'm new to Redux, so I'm not sure if there is an adopted pattern for this type of thing. I'd appreciate any advice or pointers in the right direction. Thanks.

[jeloi]

Sorry, the other option I've discovered is using a custom rootReducer. Technically, this reducer wouldn't have to be at the root; it could just be the Lowest Common Ancestor of the parts of the state tree that are dependent on each other.

[gaearon]

If the data can be computed from a “lesser” state, don't hold it in the state. Use memoized selectors as described in Computing Derived Data.

If it cannot, indeed, use a single reducer that may (if desired) pass additional parameters to the reducers or use their results:

function a(state, action) { }
function b(state, action, a) { } // depends on a's state

function something(state = {}, action) {
  let a = a(state.a, action);
  let b = b(state.b, action, a); // note: b depends on a for computation
  return { a, b };
}

[melnikov-s]

Thanks @gaearon for that snippet. I've quickly ran into this issue myself when attempting to port a widget over to redux and have spent sometime trying to find a community sanctioned solution. Perhaps this is something that can be more prominent within the documentation as I'd imagine it's rather common to have dependent state.

It also appears that it would be trivial to pass the entire state tree as a optional third parameter within the innards of the combineReducers function. Doing so would facilitate this very issue though I'm not experienced enough with redux to have any sense as to whether it would be a good or bad idea. Thoughts?

[timdorr]

It's got its own section in the docs, so I think it's pretty prominent personally. 😄

You don't have to use combineReducers if you don't want to. It's a useful utility, but not a requirement. Perhaps reduce-reducers or redux-actions is more your style?

[melnikov-s]

If the data can be computed from a “lesser” state, don't hold it in the state.

It's got its own section in the docs, so I think it's pretty prominent personally.

Ok, I think it finally clicked for me. Thanks!

[skortchmark9]

"If the data can be computed from a “lesser” state, don't hold it in the state."

What if the data can only be computed from a "lesser" state combined with the payload of an action?

[neverfox]

When you need different parts of the state tree to resolve the effects of single action that cannot be handled in a mutually exclusive way in each branch, use reduce-reducers to combine the reducer produced by combineReducer with your cross-cutting reducer:

export default reduceReducers(
  combineReducers({
    router: routerReducer,
    customers,
    stats,
    dates,
    filters,
    ui
  }),
  // cross-cutting concerns because here `state` is the whole state tree
  (state, action) => {
    switch (action.type) {
      case 'SOME_ACTION':
        const customers = state.customers;
        const filters = state.filters;
        // ... do stuff
    }
  }
);

[gastonmorixe]

@neverfox Thank you for that! exactly what I was looking. Do you know any other way of either accessing the root state from the combined reducer or re-architecturing something?

[gaearon]

@imton

For your particular example I'm not sure why don't want to let different reducers to handle the same actions. That's pretty much the point of using Redux. Please see https://gist.github.com/imton/cf6f40578524ddd085dd#gistcomment-1656424.

I don't think “cross-cutting” reducers are generally a good idea. They break encapsulation of individual reducers. It's hard to change internal state shape because some other code outside reducers might rely on it.

On the opposite, we recommend not relying on the state shape anywhere except reducers themselves. Even components can avoid relying on the state shape if you export "selectors" (functions that query the state) from the same files as reducers. Check out shopping-cart example in the repo for this approach.