First, this code could be cleaned up a little. The action types should definitely be constants -- something like ActionTypes.CHANGE_LOCATION. Using lodash's _.defaults is also a lot more terse than Object.assign. And if you're a real stickler for minimalism: https://github.com/acdlite/redux-actions#handleactionsreduce...
The real power of reducers is composability. For example, I would almost certainly store the "selected" part of the state in a separate reducer. In my personal experience, reducers rarely respond to more than 3-4 actions.
As for the reason to do this instead of setState -- the whole point is to completely encapsulate state into something that's reproducable, trackable, and removable. Almost all of the components you write should be "dumb" -- that is, they just take properties and render some JSX. Then you have a few "smart" components who know about the state and send the data down to it's "dumb" children. Redux/Flux allows your application to be as stateless as possible, which is where React really shines.
If you support ES6/ES7 in your build cycle then we are big fans of the spread operator which can be used instead of _.default, Object.assign. For example:
case 'CHANGE_LOCATION':
return {
...state,
location: action.location
}
The real power of reducers is composability. For example, I would almost certainly store the "selected" part of the state in a separate reducer. In my personal experience, reducers rarely respond to more than 3-4 actions.
As for the reason to do this instead of setState -- the whole point is to completely encapsulate state into something that's reproducable, trackable, and removable. Almost all of the components you write should be "dumb" -- that is, they just take properties and render some JSX. Then you have a few "smart" components who know about the state and send the data down to it's "dumb" children. Redux/Flux allows your application to be as stateless as possible, which is where React really shines.