Add a "Structuring Reducers" recipe

[markerikson]

We really, really need a page talking about approaches, guidelines, and suggestions for organizing reducer logic. I've been saying I want to write this for a while, but have been too busy so far. I'm still up for it, but further suggestions and/or offers of help would be appreciated.

WIP page: https://github.com/markerikson/redux/blob/structuring-reducers-page/docs/recipes/StructuringReducers.md

Initial sketch of possible topics:

• Understanding that you really only have one reducer function, which is just subdivided for maintainability and simplicity
• Understanding "reducer composition" and that you can break things down using plain ol' functions
• The basic rules of reducers: (state, action) -> newState, immutable updates, and one other item I've said before but I'm not remembering at the moment
• Emphasis that combineReducers is simply a utility function for the common use case of delegating update logic based on state domain organization, and not a requirement
• That defining object keys when using createReducers is, effectively, defining the name/shape of your state (not always clear when using ES6 object literal shorthand - naming of imported reducer functions matters!)
• That "actions are passed to all reducers" only if you're using combineReducers
• Passing different chunks or all of the state to a sub-reducer based on need for that action
• Initializing state
• Normalizing data
• Updating normalized data
• Updating data immutably in general, particularly nested data and arrays, and how just using a variable assignment doesn't mean you've "made a copy"
• Reusing logic and creating reducers that can be "targeted"
• A whole bunch of other stuff that has crossed my mind at various points and that I'm not thinking of right now, but hopefully will remember later

Random related links:

• A concern on combineReducer, when an action is related to multiple reducers #601
• Stopping state from growing forever (or: limiting displayed state) #644
• Best practice for updating dependent state across different branches of the state tree? #749
• How to create a generic list as a reducer and component enhancer? #822
• Document Redux Antipatterns #857
• A call for quality articles, examples, and resources #1014
• Add “Combining reducers” recipe #1018
• Recommendations for best practices regarding action-creators, reducers, and selectors #1171
• Document required default state in reducer #1617
• Same action for different state parts #1628
• Make dependent reducer explanation more prominent #1653
• mapStateToProps() not being called #1726
• Everything seems to need a UUID #1602 (comment)
• Normalising state and garbage collection #1824
  More on reusability for custom components. #1850
• https://gist.github.com/deanius/f380994d117dffb5b625a7871a4fa893
• http://bbarr.github.io/code/2015/12/23/redux-with-pattern-matching.html
• https://www.reddit.com/r/javascript/comments/42ey9e/redux_reducer_composition_without_slicing_state/
• http://www.code-experience.com/problems-with-flux/
• https://twitter.com/dan_abramov/status/745248569599397888
• http://stackoverflow.com/questions/38012852/users-sees-one-part-of-deeply-nested-state-should-visible-properties-be-at-top/38017227#38017227
• http://stackoverflow.com/questions/33749759/read-stores-initial-state-in-redux-reducer/33791942
• [discussion] how can we improve state management? choojs/choo#252

Some overlap with the performance/optimization discussions in #1783 , the store organization mention in http://redux.js.org/docs/FAQ.html#organizing-state-nested-data , and the concepts in http://redux.js.org/docs/recipes/ComputingDerivedData.html .

[blvdmitry]

This may help a bit https://github.com/nosovsh/reduceless

[markerikson]

@bananabobby : thanks for the link, but I'm looking to document and clarify idiomatic Redux usage.

[gaearon]

Related http://stackoverflow.com/questions/37647178/is-there-an-idiomatic-way-to-test-nested-state-branches/37647357#37647357

[markerikson]

Reactiflux quote:

[8:33 PM] Francois Ward: where state lives is more a matter of how you plan on manipulating it than anything else.
[8:34 PM] Francois Ward: so if you have, let say a "loading: true/false" flag that -always- updates when you set some entity, it probably should live there.
[8:34 PM] Francois Ward: if its completely independant, changes separately, etc, then it should be its own thing.
[8:34 PM] Francois Ward: as you develop apps you often will refactor that stuff.
[8:35 PM] Francois Ward: since the relationship between actions, components and reducers is completely loose and maleable, it can change all the time.

[gaearon]

This might be useful: http://stackoverflow.com/questions/37738268/how-to-avoid-race-conditions-when-fetching-data-with-redux/37738420#37738420

[axelboc]

I could use some advice around using combineReducers when some slices of the state are static and don't need to be reduced. Here is a contrived example:

// This is what I'd like the state to look like:
{
  isUserSignedIn: true, // static, hydrated data - doesn't need a reducer
  todoTemplates: [...], // same
  todos: [...] // hydrated then manipulated - needs a reducer
}

// This is one way of making it work:
const reducer = combineReducers({
  isUserSignedIn: (state = false) => state, // basically a noop reducer
  todoTemplates: (state = []) => state, // same
  todos: todosReducer
});

The solution above is not very practical and scalable when the number of static slices of the state increases. I can think of a couple of other ways to make this work, but neither really stands out as the right solution:

• don't use combineReducer => not scalable
• move all the static data under a common key, like static, and use a noop reducer on that => scalable, but static is kind of ugly and doesn't describe what the data actually is (and there may not be a name that does, since all the static sub-keys may not have anything in common).

[markerikson]

Not really intended as a Q&A thread, but that's definitely an interesting question I haven't considered before.

My initial thought was that a static value like that shouldn't really be in Redux state, but given that it's something server-hydrated, I can see a point to it. I've actually got some static-ish data coming back in my host page (user full name, etc), and at the moment a couple of my components are just referencing window.theVariableFromTheServer, but that's an intriguing idea now that I think about it.

I would think that putting it under a staticData key with a noop reducer would be reasonable. Suppose the big question is how much of this type of data is there, and where is it coming from.

[naw]

@axelboc here are a couple of options:

1. Don't put static stuff in the store.
2. Just write your own root reducer which keeps all keys of state, and then overrides them with whatever your combined reducers returns. In other words, static keys are kept, and dynamic keys can still use combineReducers

combinedReducers = combineReducers({
  todos: todosReducer
 })

rootReducer = function(state, action) {
  return Object.assign({}, state, combinedReducers(state, action));
}

[naw]

Also see this issue: #1457

In particular, Dan's comment here: #1457 (comment)

[axelboc]

Wow, thanks! This definitely should go in the docs. I'm going with your second solution @naw, as dealing with static data the same way as dynamic data will lead to the cleanest code in my situation.

This custom root reducer is so straightforward, logical and convenient, that it comes a little as a surprise to me that it's not already a built-in feature of combineReducers (perhaps an opt-in feature). Anyway, I'm sure there are reasons why it's not, and this is definitely not the thread for it... So thanks for your help!