6 ms·

I'm a Redux maintainer. I agree with the points Robin made, and want to toss out a few additional bits of info. There's been a lot of chatter on social media

I'm a Redux maintainer. I agree with the points Robin made, and want to toss out a few additional bits of info. There's been a lot of chatter on social media over the last couple years suggesting Redux is dying or no longer needed. While it's true that there's a number of other options available, and that there's not as much _need_ to use Redux right away as there used to be, there's still plenty of good reasons to use Redux. In addition, Redux continues to be very widely used, and I've seen quite a few major apps choose to use it over the last year. I talked about these aspects in my Reactathon 2019 talk on "The State of Redux" [0] and my post "Redux - Not Dead Yet!" [1]. We recently released a new official package called Redux Toolkit [2], which 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. It's now our recommended approach for writing Redux logic. It's also written in TypeScript, and the API is designed to provide a great experience in TS apps. We're currently working on an ongoing major rewrite of the Redux core docs [3], which has several goals: updating content to better match today's target dev audience (removing references to "Flux", etc), simplifying explanations, encouraging easier patterns, and adding additional content and guidance on real-world usage. As part of that, we've added a new "Style Guide" page [4], which has our recommended patterns and practices for writing good Redux code. We're specifically emphasizing and recommending patterns that simplify the amount of code you have to write, like using Immer for immutable updates, using the "ducks" structure for files and logic, treating actions as "events" rather than "setters", and so on. Earlier this year, we also released new versions of React-Redux. v7.0 was a complete rewrite of the internals to improve performance, and v7.1 added a new React hooks API [5] as an alternative to the classic `connect()` API. If you're interested in some of the behind-the-scenes details on how these libraries have evolved, see my posts "The History and Implementation of React-Redux" [5] and "Redux Toolkit 1.0" [6]. If anyone's got any questions, ask away! [0] https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state... [1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... [2] https://redux-toolkit.js.org https://redux-toolkit.js.org [3] https://github.com/reduxjs/redux/issues/3592 https://github.com/reduxjs/redux/issues/3592 [4] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide [5] https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor... [6] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/ https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

guu 7y ago
In the official FAQ it says something to the effect of “You’ll know when you need redux.” Recently there’s some backlash surrounding the use of redux and I’d be interested in hearing about projects (preferably open source so we can see the code) that were using the built in react state management tools and came to the conclusion they were not sufficient.
- modernerd 7y ago
  WordPress's Gutenberg editor is built on top of Redux: https://developer.wordpress.org/block-editor/packages/packages-data/#comparison-with-redux https://developer.wordpress.org/block-editor/packages/packag...
weeksie 7y ago
This is disappointing. Partially for bikeshed reasons, but also for practical ones. Redux thunk is an anti pattern as far as I'm concerned but you're including it by default? Why? Just because it's the first (bad) decision people make when trying to handle async code doesn't mean it's the one that should be canonized. The createAction function is unnecessarily verbose and the createReducer function obscures more than it abstracts.
- acemarke 7y ago
  I find your concerns very confusing. In order: Thunks are the most widely used middleware by a large margin [0], and we have frequently received complaints that there is no async middleware included in the Redux store by default. Thunks were in fact part of the store during the original development phase [1], but were made separate once the middleware API was defined [2]. Thunks are effectively the minimum viable way to write async logic that has access to interacting with the Redux store, so we include that in RTK out of the box to make that possible. Sagas, observables, and other similar middleware are far too heavyweight and complex for us to endorse as the default async approach. I also strongly disagree that thunks are an "anti-pattern", and find them to be a highly useful tool (and especially so now that `async/await` syntax makes it even easier to write more complicated async logic in a readable form) [3]. You are always welcome to add another middleware or disable thunks as part of the store setup process instead if you want. I don't see how this: const addTodo = createAction("todos/add") is more verbose than this: const addTodo = (text) => { return { type: "todos/add", payload: text } } We've had a version of `createReducer` shown in the "Reducing Boilerplate" docs page [4] for years, and there are literally hundreds of similar "lookup table"-type utilities out there. Including this in RTK is a no-brainer. It's even more valuable, because ours uses Immer inside to let you write "mutative" immutable update logic instead of having to nest spread operators. I don't see how this is "obscuring" anything. Finally, our recommendation is that most of the time you shouldn't even be calling `createAction` and `createReducer` yourself. Instead, you should be using the `createSlice` function [5], which automatically generates action creators and action types for you, and calls the other two functions internally. [0] Slide 38 in https://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/ https://blog.isquaredsoftware.com/2017/09/presentation-might... [1] https://github.com/reduxjs/redux/issues/1 https://github.com/reduxjs/redux/issues/1 [2] https://github.com/reduxjs/redux/pull/63#issuecomment-110575809 https://github.com/reduxjs/redux/pull/63#issuecomment-110575... [3] https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th... [4] https://redux.js.org/recipes/reducing-boilerplate#generating-reducers https://redux.js.org/recipes/reducing-boilerplate#generating... [5] https://redux-toolkit.js.org/api/createSlice https://redux-toolkit.js.org/api/createSlice

guu 7y ago

In the official FAQ it says something to the effect of “You’ll know when you need redux.” Recently there’s some backlash surrounding the use of redux and I’d be interested in hearing about projects (preferably open source so we can see the code) that were using the built in react state management tools and came to the conclusion they were not sufficient.

modernerd 7y ago
WordPress's Gutenberg editor is built on top of Redux: https://developer.wordpress.org/block-editor/packages/packages-data/#comparison-with-redux https://developer.wordpress.org/block-editor/packages/packag...

weeksie 7y ago

This is disappointing. Partially for bikeshed reasons, but also for practical ones. Redux thunk is an anti pattern as far as I'm concerned but you're including it by default? Why? Just because it's the first (bad) decision people make when trying to handle async code doesn't mean it's the one that should be canonized. The createAction function is unnecessarily verbose and the createReducer function obscures more than it abstracts.

acemarke 7y ago
I find your concerns very confusing. In order: Thunks are the most widely used middleware by a large margin [0], and we have frequently received complaints that there is no async middleware included in the Redux store by default. Thunks were in fact part of the store during the original development phase [1], but were made separate once the middleware API was defined [2]. Thunks are effectively the minimum viable way to write async logic that has access to interacting with the Redux store, so we include that in RTK out of the box to make that possible. Sagas, observables, and other similar middleware are far too heavyweight and complex for us to endorse as the default async approach. I also strongly disagree that thunks are an "anti-pattern", and find them to be a highly useful tool (and especially so now that `async/await` syntax makes it even easier to write more complicated async logic in a readable form) [3]. You are always welcome to add another middleware or disable thunks as part of the store setup process instead if you want. I don't see how this: const addTodo = createAction("todos/add") is more verbose than this: const addTodo = (text) => { return { type: "todos/add", payload: text } } We've had a version of `createReducer` shown in the "Reducing Boilerplate" docs page [4] for years, and there are literally hundreds of similar "lookup table"-type utilities out there. Including this in RTK is a no-brainer. It's even more valuable, because ours uses Immer inside to let you write "mutative" immutable update logic instead of having to nest spread operators. I don't see how this is "obscuring" anything. Finally, our recommendation is that most of the time you shouldn't even be calling `createAction` and `createReducer` yourself. Instead, you should be using the `createSlice` function [5], which automatically generates action creators and action types for you, and calls the other two functions internally. [0] Slide 38 in https://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/ https://blog.isquaredsoftware.com/2017/09/presentation-might... [1] https://github.com/reduxjs/redux/issues/1 https://github.com/reduxjs/redux/issues/1 [2] https://github.com/reduxjs/redux/pull/63#issuecomment-110575809 https://github.com/reduxjs/redux/pull/63#issuecomment-110575... [3] https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th... [4] https://redux.js.org/recipes/reducing-boilerplate#generating-reducers https://redux.js.org/recipes/reducing-boilerplate#generating... [5] https://redux-toolkit.js.org/api/createSlice https://redux-toolkit.js.org/api/createSlice