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.
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.