5 ms·

Hi, I'm a Redux maintainer. If you haven't looked at Redux recently, you should look again. "Modern Redux" code is drastically simpler than the Redux code you

Hi, I'm a Redux maintainer. If you haven't looked at Redux recently, you should look again. "Modern Redux" code is drastically simpler than the Redux code you've probably seen before. In particular, our official Redux Toolkit package [0] and the React-Redux hooks API [1] make it much simpler to write Redux code, by auto-generating action creators, writing reducers as object lookup tables instead of switch statements, letting you write "mutating" immutable updates in reducers, and providing good defaults out of the box and utilities that handle common use cases. FWIW, we've just completely rewritten the official tutorials in our docs to show how much simpler "modern Redux" code is, as well as better explain the fundamentals and why many of these patterns exist: - The "Redux Essentials" tutorial [2] teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit - The "Redux Fundamentals" tutorial [3] teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns In addition, we've added a "Style Guide" docs page [4] that lists our recommended patterns and best practices, which help you write Redux logic that is simpler, easier to understand, and easier to maintain. That includes things like "write Redux logic as single file 'slices'", "put as much logic as possible in reducers", "model actions as 'events', not 'setters'", and so on. We've gotten a lot of great feedback telling us that RTK and the docs improvements have really made it a lot easier for people to learn and use Redux effectively. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co... [3] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview [4] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide

chrismaltby 6y ago
I can second that, I’ve just recently started migrating my open source application [0] to use Redux Toolkit and the hooks API (+Typescript) and it’s been a pleasure to use and MUCH less boilerplate than the previous implementation. Thanks for your efforts working on this! [0] https://github.com/chrismaltby/gb-studio/tree/v2beta https://github.com/chrismaltby/gb-studio/tree/v2beta
- acemarke 6y ago
  Nice, glad to hear that! Yeah, RTK is written in TS and specifically designed for a good TS usage experience with a lot of type inference, and the React-Redux hooks API is _much_ simpler to use with TS since it's really just a matter of declaring the type of `state` in your selectors. (Well, okay, to use thunks in components you gotta supply a customized type for `dispatch` that knows it can accept thunks too.) FYI, we've got some new RTK APIs in the works that are close to alpha status that I think are really gonna surprise people and make some use cases a _lot_ nicer too. Hoping we can formally announce them here in the next couple weeks. Lemme glance at that repo you listed there... Oh wow, that's a really impressive project there, and some neat larger-scale use of RTK! Thanks for linking that. A few quick bits of feedback on your code since I've got it open: - A couple of those extra middleware look like they could maybe just be hand-written thunks instead, such as `projectMiddleware` - for `projectMiddleware` in particular, you probably ought to be doing `storeAPI.dispatch(loadProject))` instead of trying to unwrap the thunk yourself - strictly speaking, a reference to `window.width` shouldn't be in the reducer itself - the value should be in the action, preferably via the `prepare` callback. (In practice it won't really make a difference, just pointing it out as an FYI.) - always nice to see actual uses of `undoable()` in the wild :)
  - chrismaltby 6y ago
    I really appreciate you taking the time to code review the Redux store! This is some really great advice that I'll definitely be implementing. The project has definitely been a big learning experience :) Very much looking forward to these new RTK APIs. Thanks again for your help.
preommr 6y ago
God I hate redux. I hate that it got chosen as the de facto solution, and that there was such a strong push for it as the main state management solution for react. Even though redux devs themselves have come out and said that it's not for every situation. Where does that leave people? I really think there should be a greater focus to be more ergonomic rather than theoretically good. There should be one package that someone can just jump into. Separating react-redux, redux, and now redux-tookit is just frustrating. I just get this gut feeling with redux that people just wrote and wrote stuff, without really stopping and squashing it down. The fact that part of the messaging with using a toolkit also involves reading up on the essentials is a problem. Even if the problem space is very complex there shouldn't be this much information - I think it might be easier to learn some programming languages than the entirety of the redux ecosystem. And frankly, I don't even think the problem is that complicated, the basic flux model isn't that complicated. And yet it's been made to be so complicated. I recently did a refresher, and on the react-redux example, just in the intro of a basic todolist, there's ~50 things that are highlighted - implying you should remember them - in just the section of setting up a store. Not the entire section on stores, just the intro outlining the brief overview of the rest of the tutorial. There is just so much stuff. I don't even think the toolkit makes things that much simpler either. It's a step in the right direction, but it feels really leaky when I get into the intermediate and advanced sections.
- acemarke 6y ago
  Sorry to hear that :( I get what some of what you're saying here, but I also feel a couple of these complaints are misguided. For one thing, the Redux team has never intentionally tried to make Redux "the main state management tool for React". We've never deliberately sold it that way, and goodness knows the React team has said "React is the only official state management tool for React". Redux got popular because it solved the problems people were dealing with when it came out, better than the existing tools in the ecosystem, at a time when React was taking off. We've done our best to clarify in the docs when it does actually make sense to use Redux. Redux Toolkit is still Redux. You're still writing reducers, creating a store, dispatching actions, and updating the UI based on state. RTK just allows you to do so with less code. So, the "Essentials" tutorial starts by introducing those terms, concepts, and data flow, because you need to understand those regardless of how you're writing Redux logic. While Redux _is_ normally used with React, it's also UI-agnostic, hence the separation from React-Redux, and using it with other UI frameworks is a valid use case that we support. We had some long debates about whether to add these additional APIs into the Redux core [0] [1], and concluded that there was too much inertia around the existing Redux ecosystem to build those into the core `redux` package. As it is, even though RTK isn't required, we've had folks say they didn't like some of the opinions we've built into RTK (like using Immer for writing reducers). So, combining all three of those packages into a single super-package is not feasible at this point. I've tossed around the idea of trying to merge the Redux core, React-Redux, and RTK docs into one site, but that would likely require merging all three libs into a monorepo. Not impossible, but not something that's likely to happen any time soon, if only because my own time is very limited and I have a lot of other docs work I need to focus on [2]. Which specific docs page are you referring to? You said "intermediate" and "advanced" - sounds like you're referring to the RTK docs site tutorials [3]? FWIW, I wrote those a year ago, and at the time the main Redux docs were frankly very out of date. I've spent much of this year rewriting the Redux core tutorials, as listed above, and those Redux tutorials are where I would direct anyone who's new to Redux or really wants to know about RTK. We do also have an open issue to discuss what tutorial content should be on the RTK docs site [4], and tbh I'm really not sure _what_ tutorial content should actually be on the RTK site now that the "Essentials" and "Fundamentals" tutorials exist in the core docs. You're right that the actual Redux core itself isn't very complicated, but the biggest issue is trying to teach people to "think in Redux". In fact, it's kind of _because_ the core is so small that there's a lot of documentation needed - so much of this is actually in the patterns around how to use Redux effectively. Anyway, if you can point to some more concrete concerns or have specific suggestions on how we can improve things, I'm very interested - please feel free to comment over in the issues. [0] https://github.com/reduxjs/redux/issues/3321 https://github.com/reduxjs/redux/issues/3321 [1] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/ https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [2] https://github.com/reduxjs/redux/issues/3592 https://github.com/reduxjs/redux/issues/3592 [3] https://redux-toolkit.js.org/tutorials/intermediate-tutorial https://redux-toolkit.js.org/tutorials/intermediate-tutorial [4] https://github.com/reduxjs/redux-toolkit/issues/371 https://github.com/reduxjs/redux-toolkit/issues/371
thunderbong 6y ago
Why? Why should I look at "Modern Redux"? Why wasn't enough thought put in in the original Redux? Like preommr mentioned, the basic flux model isn't that complicated. Why do you guys complicate things? Why do you think new concepts are required? And new terminology? Why do you write so much code? Why don't you see how these things have been done in the past? This has been done in Mithril for ages. My suggestion is - next time you guys decide to create something new, don't just keep thinking of new concepts and write code. It's all been done before. Just make it easier to use. So, no, I'll not be looking at Redux, now or in the future. Because I've got applications to deliver and the end user doesn't give a shit about how fantastic your architecture is, if it takes ages to understand, implement, maintain & debug.
- acemarke 6y ago
  > Why wasn't enough thought put in in the original Redux? Because times change, ecosystems change, patterns change, and user bases change. Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place? > Just make it easier to use And that's exactly what we did :) "Modern Redux" code is different because: - We've seen how people have used Redux in practice, what they wanted to do, and what problems they've run into - We've seen what solutions and other Redux-related libraries the community has invented to solve their problems - And there's new tools and APIs that have come out since Redux was created, like Immer for immutable updates and React Hooks for writing reusable logic in React components Like I said, this isn't about "new Redux concepts". It's still state, actions, reducers, dispatching, and subscribing in the UI. It's just much less code to do it, and prevention of common mistakes while using Redux. That means smaller bundles, faster development, and fewer bugs. This tutorial page shows how Redux Toolkit simplifies all the older Redux logic patterns: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... I can't force you or anyone else to use RTK, or to use Redux. If you've got other options that are working for you, please use them. I'm just pointing out that we _have_ specifically addressed the very concerns you're raising, and if you are genuinely concerned about those issues, you _might_ want to take a look at what we've put together... and I've got a whole lot of enthusiastic RTK users who can vouch for how it's made their development lives and Redux usage experience a lot better.
robertlagrant 6y ago
Hm, fair enough. That sounds cool. I've found React useState pretty amazing so far; I'll have to check out what's changed!

chrismaltby 6y ago

I can second that, I’ve just recently started migrating my open source application [0] to use Redux Toolkit and the hooks API (+Typescript) and it’s been a pleasure to use and MUCH less boilerplate than the previous implementation. Thanks for your efforts working on this! [0] https://github.com/chrismaltby/gb-studio/tree/v2beta https://github.com/chrismaltby/gb-studio/tree/v2beta

acemarke 6y ago
Nice, glad to hear that! Yeah, RTK is written in TS and specifically designed for a good TS usage experience with a lot of type inference, and the React-Redux hooks API is _much_ simpler to use with TS since it's really just a matter of declaring the type of `state` in your selectors. (Well, okay, to use thunks in components you gotta supply a customized type for `dispatch` that knows it can accept thunks too.) FYI, we've got some new RTK APIs in the works that are close to alpha status that I think are really gonna surprise people and make some use cases a _lot_ nicer too. Hoping we can formally announce them here in the next couple weeks. Lemme glance at that repo you listed there... Oh wow, that's a really impressive project there, and some neat larger-scale use of RTK! Thanks for linking that. A few quick bits of feedback on your code since I've got it open: - A couple of those extra middleware look like they could maybe just be hand-written thunks instead, such as `projectMiddleware` - for `projectMiddleware` in particular, you probably ought to be doing `storeAPI.dispatch(loadProject))` instead of trying to unwrap the thunk yourself - strictly speaking, a reference to `window.width` shouldn't be in the reducer itself - the value should be in the action, preferably via the `prepare` callback. (In practice it won't really make a difference, just pointing it out as an FYI.) - always nice to see actual uses of `undoable()` in the wild :)
- chrismaltby 6y ago
  I really appreciate you taking the time to code review the Redux store! This is some really great advice that I'll definitely be implementing. The project has definitely been a big learning experience :) Very much looking forward to these new RTK APIs. Thanks again for your help.

preommr 6y ago

God I hate redux. I hate that it got chosen as the de facto solution, and that there was such a strong push for it as the main state management solution for react. Even though redux devs themselves have come out and said that it's not for every situation. Where does that leave people? I really think there should be a greater focus to be more ergonomic rather than theoretically good. There should be one package that someone can just jump into. Separating react-redux, redux, and now redux-tookit is just frustrating. I just get this gut feeling with redux that people just wrote and wrote stuff, without really stopping and squashing it down. The fact that part of the messaging with using a toolkit also involves reading up on the essentials is a problem. Even if the problem space is very complex there shouldn't be this much information - I think it might be easier to learn some programming languages than the entirety of the redux ecosystem. And frankly, I don't even think the problem is that complicated, the basic flux model isn't that complicated. And yet it's been made to be so complicated. I recently did a refresher, and on the react-redux example, just in the intro of a basic todolist, there's ~50 things that are highlighted - implying you should remember them - in just the section of setting up a store. Not the entire section on stores, just the intro outlining the brief overview of the rest of the tutorial. There is just so much stuff. I don't even think the toolkit makes things that much simpler either. It's a step in the right direction, but it feels really leaky when I get into the intermediate and advanced sections.

acemarke 6y ago
Sorry to hear that :( I get what some of what you're saying here, but I also feel a couple of these complaints are misguided. For one thing, the Redux team has never intentionally tried to make Redux "the main state management tool for React". We've never deliberately sold it that way, and goodness knows the React team has said "React is the only official state management tool for React". Redux got popular because it solved the problems people were dealing with when it came out, better than the existing tools in the ecosystem, at a time when React was taking off. We've done our best to clarify in the docs when it does actually make sense to use Redux. Redux Toolkit is still Redux. You're still writing reducers, creating a store, dispatching actions, and updating the UI based on state. RTK just allows you to do so with less code. So, the "Essentials" tutorial starts by introducing those terms, concepts, and data flow, because you need to understand those regardless of how you're writing Redux logic. While Redux _is_ normally used with React, it's also UI-agnostic, hence the separation from React-Redux, and using it with other UI frameworks is a valid use case that we support. We had some long debates about whether to add these additional APIs into the Redux core [0] [1], and concluded that there was too much inertia around the existing Redux ecosystem to build those into the core `redux` package. As it is, even though RTK isn't required, we've had folks say they didn't like some of the opinions we've built into RTK (like using Immer for writing reducers). So, combining all three of those packages into a single super-package is not feasible at this point. I've tossed around the idea of trying to merge the Redux core, React-Redux, and RTK docs into one site, but that would likely require merging all three libs into a monorepo. Not impossible, but not something that's likely to happen any time soon, if only because my own time is very limited and I have a lot of other docs work I need to focus on [2]. Which specific docs page are you referring to? You said "intermediate" and "advanced" - sounds like you're referring to the RTK docs site tutorials [3]? FWIW, I wrote those a year ago, and at the time the main Redux docs were frankly very out of date. I've spent much of this year rewriting the Redux core tutorials, as listed above, and those Redux tutorials are where I would direct anyone who's new to Redux or really wants to know about RTK. We do also have an open issue to discuss what tutorial content should be on the RTK docs site [4], and tbh I'm really not sure _what_ tutorial content should actually be on the RTK site now that the "Essentials" and "Fundamentals" tutorials exist in the core docs. You're right that the actual Redux core itself isn't very complicated, but the biggest issue is trying to teach people to "think in Redux". In fact, it's kind of _because_ the core is so small that there's a lot of documentation needed - so much of this is actually in the patterns around how to use Redux effectively. Anyway, if you can point to some more concrete concerns or have specific suggestions on how we can improve things, I'm very interested - please feel free to comment over in the issues. [0] https://github.com/reduxjs/redux/issues/3321 https://github.com/reduxjs/redux/issues/3321 [1] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/ https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [2] https://github.com/reduxjs/redux/issues/3592 https://github.com/reduxjs/redux/issues/3592 [3] https://redux-toolkit.js.org/tutorials/intermediate-tutorial https://redux-toolkit.js.org/tutorials/intermediate-tutorial [4] https://github.com/reduxjs/redux-toolkit/issues/371 https://github.com/reduxjs/redux-toolkit/issues/371

thunderbong 6y ago

Why? Why should I look at "Modern Redux"? Why wasn't enough thought put in in the original Redux? Like preommr mentioned, the basic flux model isn't that complicated. Why do you guys complicate things? Why do you think new concepts are required? And new terminology? Why do you write so much code? Why don't you see how these things have been done in the past? This has been done in Mithril for ages. My suggestion is - next time you guys decide to create something new, don't just keep thinking of new concepts and write code. It's all been done before. Just make it easier to use. So, no, I'll not be looking at Redux, now or in the future. Because I've got applications to deliver and the end user doesn't give a shit about how fantastic your architecture is, if it takes ages to understand, implement, maintain & debug.

acemarke 6y ago
> Why wasn't enough thought put in in the original Redux? Because times change, ecosystems change, patterns change, and user bases change. Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place? > Just make it easier to use And that's exactly what we did :) "Modern Redux" code is different because: - We've seen how people have used Redux in practice, what they wanted to do, and what problems they've run into - We've seen what solutions and other Redux-related libraries the community has invented to solve their problems - And there's new tools and APIs that have come out since Redux was created, like Immer for immutable updates and React Hooks for writing reusable logic in React components Like I said, this isn't about "new Redux concepts". It's still state, actions, reducers, dispatching, and subscribing in the UI. It's just much less code to do it, and prevention of common mistakes while using Redux. That means smaller bundles, faster development, and fewer bugs. This tutorial page shows how Redux Toolkit simplifies all the older Redux logic patterns: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... I can't force you or anyone else to use RTK, or to use Redux. If you've got other options that are working for you, please use them. I'm just pointing out that we _have_ specifically addressed the very concerns you're raising, and if you are genuinely concerned about those issues, you _might_ want to take a look at what we've put together... and I've got a whole lot of enthusiastic RTK users who can vouch for how it's made their development lives and Redux usage experience a lot better.

robertlagrant 6y ago

Hm, fair enough. That sounds cool. I've found React useState pretty amazing so far; I'll have to check out what's changed!