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.
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-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.
I think the comment you are responding to is a little harsh, but I find this part of your argument disingenuous. JavaScript's syntactic expansion is not definitely a good thing — it isn't all progress.
The rhetorical questions you have presented seem to imply that JavaScript gaining classes is obviously a good thing, whereas I strongly doubt everyone agrees. Did prototypical inheritance work? Yes. Does JavaScript still have prototypical inheritance? Also yes. Is it better to have more choice? Not necessarily. The result of this has been more fragmentation, more documentation, more for beginners to learn, more framework churn, etc.
JavaScript the language was originally invented in just 10 days, and the author himself has explained that aside from the deadline pressure, there are regrettable reasons for the language's inconsistent API.
The parent comment seems to be arguing that a library or tool should be perfect in its very first release - that the designers should have anticipated every possible use case, target audience, and piece of API design.
My point was that _everything_ in technology evolves over time, and Redux is no exception.
The Redux core _is_ exceptionally well designed, especially given that Dan and Andrew really only worked on it for a two-month stretch. During that time, they iterated on multiple ideas, particularly the transition from "stores" to "stateless stores" to "reducers", and coming up with the middleware API as a way to allow pluggable side effects logic. Similarly, the design discussion for what became `connect` [0] shows from the very first comment exactly what design constraints were relevant, and while it took some time to nail down the specifics, Dan clearly had the key criteria in mind.
At the same time, many of their early ideas about how Redux would be used turned out to be wrong. Dan assumed that people would likely only connect top-level components, and it turns out that connecting many components across the tree is better for performance. Andrew came up with the "Flux Standard Actions" standard, but his idea of having `{error: true, payload: new Error()}` and reusing the same action type for errors and successes has been completely ignored by the ecosystem - it's a lot easier to have separate action types for success and failure. They both thought that thunks were a stopgap that would quickly be replaced by something else, and neither of them could have anticipated the creation of Immer.
So, in the real world, no tool is ever designed perfectly from day 1. Requirements change and usage patterns patterns change. That's why libraries and tools publish new versions - to respond to those changing situations.
That's why we created and designed Redux Toolkit - to respond to the changes in how people want to use Redux, and the pain points they've experienced using it.
That's not what I'm focusing on, and I don't know how you've managed to interpret my comment that way.
In your comment, you said this:
> Why were ES6 classes and hooks invented?
That's why I used classes as a concrete example of the larger point that I was trying to make. My point is that change is fine, but just continually adding stuff to appease people is not necessarily a good thing. All that's happened to JavaScript — as I already pointed out — is the foot-gun now has a wider blast radius and less travel on the trigger.
> 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`?
Sorry, but all of these are mistakes. I predict that hooks will not survive the battle of time as well as react as a whole will. Arrow functions are mere syntatic sugar, but async/await was a mistake.
I could explain it, but it's already described here better than I could: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb... (scroll to "do-notation")
Have you read it? It's saying Javascript has something like 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 :)
Very much looking forward to these new RTK APIs. Thanks again for your help.
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.
With the choice to use it or not use it. Before that, they only had the choice to not use it.
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
[1] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...
[2] https://github.com/reduxjs/redux/issues/3592
[3] https://redux-toolkit.js.org/tutorials/intermediate-tutorial
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
[1] https://react-redux.js.org/api/hooks
[2] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[3] https://redux.js.org/tutorials/fundamentals/part-1-overview
[4] https://redux.js.org/style-guide/style-guide