Reducers !== Actions

[binarykitchen]

Hello folks - sorry, it's me again :)

The wonderful createSlice function takes in reducers as a parameter, then
the return object has those reducers under actions

I think we shouldn't mix up reducers with actions.

IMO reducers are great for reducing complexity, while actions are more user-oriented. Not the same thing. Thoughts?

[EskiMojo14]

createSlice optimises for the most common case - usually an action is most related to a specific "slice" of your state, and will update that state in a certain way. other slices can still respond to the action using extraReducers, and the returned action creator includes a .match method to help anything else (such as middleware) to recognise the action.

if the action truly has no "home" slice, you can use the lower level createAction utility, which is what createSlice is built on (along with createReducer).

[markerikson]

IMO reducers are great for reducing complexity, while actions are more user-oriented

I'm not sure I understand the intent of this sentence :)

Taking a step back: if you look at early Redux code, there are 3 things you typical wrote:

• a reducer function ( todosReducer ), often with switch/case statements ( case "todos/todoAdded" )
• an action creator function (todoAdded()). These have never been necessary, because you could write dispatch({type: "todos/todoAdded"}) directly, but we've always taught that action creators were a proper and expected abstraction for formatting action objects correctly.
• and since these were usually written in separate files like reducers/todos.js and actions/todos.js, there was also usually a const TODO_ADDED = "todos/todoAdded" constant in constants/todos.js, so that both the reducer and action creator files could reference it for consistency

The main point of createSlice is that only the reducer functions themselves are necessary to write at all:

• we can generate an action type string by combining slice.name and the reducer function name, so name: "todos" + todoAdded: (state, action) => {} -> "todos/todoAdded"
• and we can eliminate the need to hand-write an action creator by assuming that it takes a value that becomes action.payload by default

so at that point the only thing you have to write is the.... "reducers"!

and thus the field is named "reducers".

We then generate the action creators. So, input "reducers" -> output "actions", derived and generated.

The other insight here is that as Ben said, historically there's almost always been a 1:1 correspondence between an action and how many reducers actually listen for that action to do an update. So, we optimize for that case. Write a slice, write a reducer like todoAdded, get the action creator generated for free.

[phryneas]

The wonderful createSlice function takes in reducers as a parameter, then
the return object has those reducers under actions

This might be a misconception. A slice results in one externally accessible reducer that handles multiple actions. What you see in actions are "action creators" - functions that when called return objects (actions), that when dispatched are passed to reducers until they hit your composed slice reducer, at which part your slices inner reducer for that action is called.

[binarykitchen]

Ah, thanks everyone.

One reason I were asking this, is that I used Redux 6–7 years ago using the old dispatch({type: "todos/todoAdded"}) way, still ticking this way, to trigger an action first. Mark knows it ;)

And now I am coming back, questioning the recent changes (I might be wrong and am grateful for this discussion) 🙇🏼‍♂️
My remaining issue was that you still mention actions in reducer parameters. For example, this TODO code:

  reducers: {
    addTodo: {
      reducer: (state, action: PayloadAction<Item>) => { //<--- Action mentioned here
        state.push(action.payload)
      },
      ...
    },
  },

What comes first? An action or reducing state? Chicken or eggs? In the above createSlice code, you define reducers first.
So, I took a step back, had a glass of wine, reflected about all your wonderful input. I think you are correct.

I believe an egg (= state) comes first. Without an egg, there can't be a chick (but the question still remains, who created the egg first) 😅

That said, about the other comments:

We then generate the action creators. So, input "reducers" -> output "actions", derived and generated.

... and ...

Write a slice, write a reducer like todoAdded, get the action creator generated for free.

Awesome job. I am impressed and like it. Must have been hard work.

Perhaps naming is the issue here? Because ...

IMO reducers are great for reducing complexity, while actions are more user-oriented

... because we developers tick in user actions first, before state changes. Press the Add TODO button first. So, having it action-oriented first before reducers might welcome more developers, perhaps?

Just continuing the conversation. I don't have an answer nor solution for that now. Cheers.

[binarykitchen]

All sorted, the other discussion clarified this. Closing this discussion now. Thanks, all.