DEV Community

Discussion on: Reduce your Redux boilerplate

Collapse
markerikson profile image
Mark Erikson • Edited on

Hi, I'm a Redux maintainer. Unfortunately, I have concerns with several of the things you've shown here in this post - the code patterns shown are the opposite of how we recommend people use Redux today.

You should be using our official Redux Toolkit package and following our guidelines for using Redux with TypeScript correctly. That will eliminate all of the hand-written action types, action creators, and a lot of the other code you've shown, as well as simplifying the store setup process. You're also splitting the code across multiple files by type, and we recommend keeping logic in a single-file "slice" per feature.

In addition, we specifically teach that you should put more logic in reducers, let reducers control the state shape, model actions as "events" rather than "setters", and write meaningful action names..

Writing actions and reducers that involve "sending the entire updated entity as a payload, and then spreading it into the state" or with action types like "UPDATE_STORE" are not how we teach people to use Redux. We also tell users that you should not create unions of TS action types - there's no real benefit.

In this specific case, part of the issue is that it looks like you're trying to live-update form state in Redux. We also recommend that you don't keep form state in Redux. Instead, let form state live in local components, and then dispatch a single action at the end with the resulting data when the user is done with the form.

(Also, as a side note: having a default case of return {...state} is also wrong, because you're unnecessarily creating a new state object when nothing actually changed.)

I'd strongly recommend going through the "Redux Essentials" tutorial in the Redux docs to see how we want people to learn and use Redux today.