That would be a good place to start. Node.js is the defacto standard for JS based tooling, along with npm (node package manager) as a public module repository. There has been some evolution in the space.

If starting a project, I'd probably start with Parcel.js [1] and from there use typescript/tsx instead of JS as a core. But that's just me. I also tend to do Redux the "hard way" closer to the original structure instead of redux-toolkit, as I find it's more overhead to learn initially but avoids a lot of additional complexity over time.

1. https://parceljs.org/recipes/react/

Hi, I'm a Redux maintainer and creator of Redux Toolkit.

Can you clarify what your concerns are with RTK?

We specifically created it to simplify standard Redux usage patterns and eliminate common mistakes and bugs (like accidental mutations):

- https://redux.js.org/introduction/why-rtk-is-redux-today

We'd _like_ everyone who is writing any kind of Redux code to write that using Redux Toolkit, and we teach RTK as the default approach for using Redux. FWIW, we've had plenty of beginners tell us they were able to get started and be productive after reading through the "Essentials" tutorial in our docs, which walks folks through how to use RTK to build apps.

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.

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.

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.