Why the extra ...state in the action map?

[0x80]

I am wondering why we are required to merge in the current state in every reducer function.

const initialState = {
  selectedTagIds: [],
  tags: getTagsForLanguage('en')
}

const reducer = handleActions({
  [ADD_FILTER_TAG]: (state, { payload }) => ({ ...state, selectedTagIds: [...state.selectedTagIds, payload] }),
  [REMOVE_FILTER_TAG]: (state, { payload }) => ({ ...state, selectedTagIds: state.selectedTagIds.filter(id => id !== payload) }),
  [CLEAR_FILTER]: (state) => ({ ...state, selectedTagIds: [] }),
}, initialState)

If handleActions was something like...

function handleActions(actionsMap, initialState) {
  return (state = initialState, action) => {
    const reduceFn = actionsMap[action.type]
    if (reduceFn) {
      return {...state, ...reduceFn(state, action)}
    }

    return state
  }
}

... you could write

const reducer = handleActions({
  [ADD_FILTER_TAG]: (state, { payload }) => ({ selectedTagIds: [...state.selectedTagIds, payload] }),
  [REMOVE_FILTER_TAG]: (state, { payload }) => ({ selectedTagIds: state.selectedTagIds.filter(id => id !== payload) }),
  [CLEAR_FILTER]: (state) => ({ selectedTagIds: [] }),
}, initialState)

It makes it less verbose and harder to mess up imho

[acdlite]

Thanks for the suggestion! However, what if is state is not a plain object — what if it's an array, or an Immutable Map? Or just a number?

What if, depending on the content of the payload, we want to return the previous state (and maintain the same object reference?

Merging state every time, while similar to what React does with setState(), is against the spirit of Redux and makes too many restrictive assumptions.

[0x80]

Makes sense 😄 Thanks for clarifying this decision 👍