Show HN: Build your first real world React.js application

Which for any new tool is important. Good luck.

My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post:

  switch (action.type) {
    case 'CHANGE_LOCATION':
      return Object.assign({}, state, {
        location: action.location
      });
    case 'SET_SELECTED_TEMP':
      return Object.assign({}, state, {
        selected: {
          temp: action.temp,
          date: state.selected.date
        }
      });
    case 'SET_SELECTED_DATE':
      return Object.assign({}, state, {
        selected: {
          date: action.date,
          temp: state.selected.temp
        }
      });
    default:
      return state;
  }

What's the point with dispatching these fragile "stringly-typed" selectors, when you can just have real functions doing setState() updates on the relevant component?

I'm not trying to be snarky -- I know I'm missing something major here.

Using Redux, all or almost all of your state is stored in a global repository (the "store").

Those strings should probably be constants instead, especially for IDE auto-complete purpose, but you are never generating those manually.

Instead, your components would call "action creators", who are properly named functions, which in turn will dispatch one or several actions to the store.

In your component:

    actions.changeLocation(someLocation)

    changeLocation(location) {
        dispatch({
            type: CONSTANTS.CHANGE_LOCATION,
            payload: { 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.

    case 'CHANGE_LOCATION':
      return {
         ...state,
         location: action.location
      }