I'm just wrapping my head around Redux and I just wanted to run a question by on how
combineReducers takes a number of reducers as parameters and returns a reducer. The particular reducer created by
combineReducers only passes the part of the state assigned to a particular reducer. This way each reducer is completely in charge of its own part of the state and nothing more.
But you can write your own kind of combineReducers that could work differently. This is just to say that there is nothing special about
A reducer is just a function that takes a state and an action and returns the state with the action applied in some way. Or not, at its discretion.
For instance, in Redux it is common for separate branches of the state to handle the same (set of) actions but handle them in different ways that make sense for that part of the state. Each action is passed to all sub-reducers by
combineReducers, giving each branch's reducers a chance to either do something, or nothing.
So in most common usage, a reducer is solely responsible for a slice of the state and sub-reducers, such as those passed to combineReducers, or reducers called by your own reducers, are solely responsible for their sub-state/branch.
But your own reducers may call a sub-reducer and pass it anything you like, such as the same state that was already passed to some other reducer, or even some data it created without it ever having been available in the global state.
These things are not common, but if you see a need, and feel confident to go forward with it, you are encouraged to use what you believe works best. Great power comes with great responsibility.
combineReducers is just a helper function for a common use case. It's probably cleanest to make a single reducer responsible for a particular branch of the state, but there may be situations where you find it beneficial to do things differently. A single reducer can manage a complex object with nesting without calling any other reducer, but a common pattern is to make smaller reducers to handle parts, if the parent is getting unwieldy.
The main point is to realize that a reducer is always a pure function that takes state and an action and returns a state. How you make this happen is entirely up to you. Most developers choose to follow common patterns seen in other's code, such as Dan's Redux examples or the videos he has on egghead.io.
Treading on the beaten path is often a good way to start out because it has already been vetted.
By the same token, however, it is always important to know why something is done. Developers sometimes make things more complex than it needs to be because of following an example that either was meant for something else or wasn't thought through very well to begin with.
Also read this article by Dan.