Switch Redux logic setup to use Redux Toolkit (take 2)

Is your feature request related to a problem? Please describe. Hi, I’m a Redux maintainer. I’d like to offer a couple suggestions.

The current Redux example implementation shows use of reducers with “hand-written” immutable update logic, and has a somewhat complex store configuration. In addition, the project’s current “feature folder” structure results in multiple separate files for the Redux logic in each feature.

Describe the solution you’d like

The project should switch to using the official Redux Toolkit package to implement the Redux logic.

The project should also consider switching to use the “ducks” pattern within each feature folder.

Describe alternatives you’ve considered N/A

Additional context

Redux Toolkit is our new official, opinionated, batteries-included toolset for efficient Redux development. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire “slices” of state at once without writing any action creators or action types by hand.

We are recommending RTK as the default standard way to write Redux logic. Partly related to that, we are also recommending that developers should prefer to use “feature folders” or “ducks”, and RTK makes it particularly easy to write “ducks”-structured Redux code. (Reference: the work-in-progress Redux “Style Guide” docs page, and the RTK “Usage Guide” page.)

Since many developers will be starting their projects using react-boilerplate, it would be beneficial if Redux Toolkit was included as part of the default project setup, as it will greatly simplify the application code they write.

[BenLorantfy]

I definitely think feature folders / ducks is better than doing per-page redux. At work we’re using this pattern:

import { useInjectReducer, useInjectSaga } from "redux-injectors";

const UsersManager = function() {
  useInjectReducer({ key: "users", reducer: usersReducer });
  useInjectSaga({ key: "users", saga: usersSaga });

  return null; // Just return null. Intentionally doesn't return any UI here
}

With this folder structure

/containers
/components
/pages
/managers
  /UsersManager
    /reducer.js
    /selectors.js
    /saga.js
    /index.js

So our redux isn’t coupled to any one page or UI, but we still get the code-splitting benefits of UsersManager. We just render <UsersManager /> on any page that needs the users state.

[markerikson]

@joejordan : part of the point of RTK is that it doesn’t obfuscate the fact that you’re using Redux:

https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#defining-a-roadmap-and-clarifying-the-vision

You’re still writing reducers and dispatching actions, and setting up a store that has a reducer function and some middleware. You just don’t have to do all that work by hand any more. Besides, those aspects are “incidental complexity” - they’re not a relevant or useful part of what defines Redux.

Similarly, the “ducks pattern” reduces the incidental complexity by minimizing the number of files you have to touch.

Now, note that adding RTK as the default example here doesn’t prevent you from doing everything by hand if you really want to. It does simplify the setup and point you in an easier way of doing things by default.

And, as mentioned at the top, we are officially recommending that people should use RTK as the standard way to write Redux logic, and organize files as “feature folders” or “ducks”. You’re always welcome to do something different if you want, but my goal is to make those the “industry standard”.