On: React is 10 years old

[tracker1]

I just find that the original reducer pattern(s) are easier to deal with in practice, especially when a project is slightly larger. It's often better imho, to understand the original patterns and some of the RTK approaches kind of muddy that understanding.

I'm not saying that RTK is necessarily bad, but feel that when you're using some of those kinds of slices, or merging the constraints of the actions, mutations and the abstractions, it's harder to reason with. You aren't thinking about state as a whole, or often even your fragment.

I'll sometimes mix a few things as well... The React features for provider/consumer, etc are sometimes easier to deal with as well. YMMV based on your own needs.

[acemarke → tracker1]

Hmm. I'm a bit surprised to hear you say that writing reducers "by hand" is simpler than with RTK.

Per the docs examples (like https://redux.js.org/usage/migrating-to-modern-redux#reducer... ), hand-written reducers normally involved `switch` statements and lots of immutable updates with object spreads. Those were normally accompanied with a bunch of separate action type string constants and action creator functions.

With RTK and `createSlice`, the reducers themselves are much simpler: simple functions with "mutating" update syntax (which uses Immer to turn those into immutable updates), and the action creators get generated for free:

    import { createSlice } from '@reduxjs/toolkit'

    const todosSlice = createSlice({
      name: 'todos',
      initialState: [],
      reducers: {
        todoAdded(state, action) {
          const { id, text } = action.payload
          state.push({ id, text, completed: false })
        },
        todoToggled(state, action) {
          const matchingTodo = state.todos.find(t => t.id === action.payload)
          if (matchingTodo) {
            matchingTodo.completed = !matchingTodo.completed
          }
        }
      }
    })

    export const { todoAdded, todoToggled } = todosSlice.actions
    export default todosSlice.reducer

That's a lot less code to write, much simpler and shorter to read, _and_ it eliminates accidental mutations.

You're still writing a "slice reducer" at a time, so it's the exact same amount of state to consider (ie, a "posts reducer" that manages `rootState.posts`.

Also note that we do have a "Fundamentals" docs tutorial that teaches the underlying concepts _without_ any abstractions, but then shows how RTK simplifies those patterns:

- https://redux.js.org/tutorials/fundamentals/part-1-overview

Ultimately it's your codebase, but we really do _strongly_ want everyone working with Redux to write that code with RTK.

[tracker1 → acemarke]

I've seen the examples and worked with RTK.. I still prefer the "hard" way. And I'm not the only one.

edit: I tend to find the separation of a more basic reducer, even with the switch, easier to deal with in practice. Not to mention, that action creators that are separate are easier to integrate with thunks and async data fetching IMO. The base library for Redux does very little. And if I'm going to stray from that, I'm more inclined to use something based on Proxies that feels more natural to use in practice than RTK.