Out of curiosity, anything specific that concerned you?
If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns in practices in our Style Guide docs page [2] that should result in simpler and easier to understand code.
I’ve used Redux for years, and tried many different approaches to it. But when I look at Redux Toolkit I don’t see much of what I’ve enjoyed about Redux.
To me, Redux is just a pattern for how to handle immutable updates. Redux itself isn’t even important. Every layer of abstraction over these plain, pure functions and serializable objects just obscure the simplicity of the architecture, in my opinion. Some of the recommendations expressed in the docs are reasonable, but you don’t need a library for that, just the patterns.
In my experience a lot of the confusion beginners have with Redux is because they think it is a framework that will do things for them. In that light, it looks like there is an unnecessarily large number of parts to understand. I think they often miss the fact that there is no magic, just function composition. The clearer that is, the easier it will be to work with the code.
Before Redux was probably even an idea, when Flux was reasonably new, my boss at the time basically said this new Flux thing looked like what we needed for a project and told me to learn about what made Flux tick and start building the project on that pattern.
I dug around, I looked at Facebook's documentation and propaganda for the pattern, and I came to the conclusion that Facebook people didn't know how MVC worked and decided to invent their own thing as a replacement. Then, I started building something, and realized that Facebook's Flux dispatcher library was getting in the way.
I built my own from scratch, and suddenly I understood the elegance of the pattern. It was not at all what Facebook's marketing about it said. It was not an MVC replacement at all. It was something else entirely, and should never be treated as an MVC replacement. The explanations about how it solved problems with MVC were nonsense: it was just a different pattern, for wildly different use cases, and the MVC-replacement propaganda I read still made it seem like people at Facebook just didn't understand how to use MVC.
My dispatcher was lightweight and clean. It was one of the nicer bits of code I've written, and I'm still quite proud of it, years after leaving that job.
I was the principal dev on that project. After a couple of weeks of building a complete application with a deceptively simple architecture that did all the heavy lifting with ease, I took a day off.
It was one day. It was a Friday, which meant that for the people there a quarter of the day was taken up with meetings. Somehow, in the midst of this, disaster struck.
When I came back on Monday, I discovered that the boss and a co-worker had decided they would just replace all the guts of the application with a pile of libraries designed for MVC, but bend them into a Flux shape, kinda, sorta. The result was slower to build (q.v. JavaScript "build" crapola), slower to deploy, slower to test, and slower to operate. It was slower to debug, slower to extend, and generally miserable. It required fixing or changing something in the plumbing almost every time a feature had to get added. My work on a small, beautiful, efficient architecture was destroyed, and nothing we ever did with that application ever actually required any of what they did to it.
They told me I hadn't documented how to use the architecture in place well enough, so they had to rewrite it to get anything done, but the result was half-broken, and I had to finish what they started to be able to continue myself on Monday, and they never actually did anything with what they created that justified that claim.
A couple months later, I learned they hadn't actually looked at the documentation I wrote at all. They just decided that my bespoke implementation must be wrong because I didn't use existing tools. Well, shit, I didn't need existing tools. The whole dispatcher was something like twenty lines of code. The rest of the basic structure was in parts even smaller than that. The "rewrite" of the system was probably a thousand lines of library code (I'm guessing; I didn't count) and close to two hundred lines of junk around them to make things fit together, all so we could write a bunch of boilerplate for every single thing we wanted to do thereafter.
(Note that my references to all this code excludes the React tools themselves, installed directly from npm because yarn wasn't available yet.)
long story short:
I think I understand what you mean about a pattern, as opposed to a framework or toolset. Also, even if the origins of Flux (and, thus, ultimately of Redux) were in some Facebookers possibly grossly misunderstanding how to apply the MVC pattern, Flux as a pattern was an excellent approach to addressing some specific needs for application architecture.
- Babel transpilation aspect (time it takes to build, difficulties associated with ad-hoc debugging in production)
- Bundling/packaging aspect (same reasons as above; time it takes to build, debugging difficulties).
- Huge number of unnecessary dependencies which adds risks/vulnerabilities to projects.
You could argue that it's not React's fault, that it's more about the tooling but I think that it's React's stance on inlining HTML with JavaScript (JSX) which had paved the way for all that bulkiness. From the beginning the project wrongly assumed that:
- Transpilation and bundling doesn't have any costs.
- Dependencies (those needed to do all that fancy transpilation and essentially re-implementing the way the DOM works) don't carry any additional risk and are not a threat to application security, maintenance...
I personally loathe JSX, not because of JavaScript, but because it's a wholly unnecessary different syntax for JavaScript that just forces me to deal with SGML/XML problems in a new and more painful way, because it has crept into the application logic as well.
Yeah, the toolkit does help a lot actually, I do appreciate you guys for coming up with that. But I wished that it was more like that from day 1. As others have mentioned, it was the "Redux Experience", the sheer verbosity and redundancies that went along with it, for not much gain imo. I'd have liked a lighter abstraction layer.
Yeah, a number of folks have said "we wish RTK is how Redux always was". I wish that too, but there's no way we (or more specifically Dan and Andrew) could have come up with Redux Toolkit's API at the beginning.
For background, please read my two "Tao of Redux" posts posts [0] [1] to understand why Redux was built this way to begin with. Specifically, it was designed to have a minimal core, and be extensible.
In addition, given the existing Flux library APIs, _and_ that Immer didn't exist, there's no way the Redux Toolkit API would have been feasible at the time. We were only able to come up with it after years of watching how people actually used Redux in practice, and what libraries they were writing on top of Redux to solve specific problems. (People have pointed out that RTK feels kind of like Vuex, which makes sense - Vuex was inspired from Redux's API to begin with.)
Software design is an iterative process. It's based on trying to solve problems, at a specific point in time, with inspiration from existing tools and technologies, and constrained by what is actually available at the time. AngularJS, Backbone, Flux, Redux, Vuex, Immer, NgRx, Redux Toolkit... all of these tools have specific inspirations and problems they were trying to solve. Understanding _why_ tools were created is hugely important.
On that note, my post on "Redux Toolkit 1.0" [2] covers how and why we were able to design RTK's API this way.
I'll have to look at that the next time I need to build the kind of JavaScript app for which it's appropriate. I haven't done that kind of work in a couple years or so.
Not OP but: You probably know the answer to your own question, since I'm guessing you made Toolkit to scratch your own itch! :) The "Redux Experience" is a bit overwhelming, boilerplatey, verbose and full of gotchas. Structures are all over the place. IMO that is solved by Toolkit.
The only problem with Toolkit is that it's not Redux. People don't know it yet, and I have to fight to convince people it's good enough. In an ideal world for me you'd be able to deprecate old Redux and just replace it with Toolkit.
It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it.
What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested immutable update logic by hand, making a mistake in that immutable update logic and causing accidental mutations, etc [0].
I do understand the suggestion to "replace the Redux core with RTK", and I take it as a great compliment that people suggest that. However, it can't happen, because a lot of people are already using Redux with their own customizations and abstractions. Changing the Redux core to suddenly include a bunch of other dependencies would not be what they want.
The other aspect is that the Redux core was designed from the beginning to be unopinionated, while RTK is _deliberately_ opinionated. Not all Redux users want RTK's opinions. As it is, we've had folks who didn't like the fact that RTK _is_ opinionated and requires use of Immer in our `createReducer` and `createSlice` APIs.
We had a long discussion issue about whether it made sense to add things like this to the Redux core (which was actually part of what prompted us to create RTK in the first place) [1].
FWIW, we explicitly recommend RTK as the standard way to write Redux logic [2], and now that Redux Toolkit 1.3 is out with some new APIs [3], my next task is to create a new "Quick Start" tutorial page for the Redux core docs [4] that does actually teach Redux using RTK as the default syntax, ie, "this _is_ how you write Redux code", in the same way that the Apollo docs teach Apollo-Boost as the default way to use Apollo.
I mean the problems is that it's not Redux itself. People have to actively look for RTK to use it, and few do. I wish you guys had replaced Redux with RKT and moved redux to @reduxjs/core like proposed on the issue and proclaimed "Redux is dead, long live Redux!"
Starting a project with Vanilla Redux is like starting a Vanilla PHP or Vanilla Javascript project: you're on your own. And most people don't really have a very big grasp on the full concept and just blindly follow some rando tutorial they saw in 2017 or 2018, because that's the best they can do.
That's kind of fine! I don't really mind using different architectures, or even different frameworks. But in large projects the inconsistencies from different approaches generates bit rot and lot of bikeshedding.
I find RTK really good (maybe I'm biased because I've been using Immer from day 1), but that's beside the point: the best part is that it removes the least productive and most boring parts IMO of building software in large teams: bikeshedding, boilerplate and lack of structure in large projects.
As I said, we're in the process of rewriting the docs (and by "we", I mean "me", because I'm not getting any assistance with it so far). The "Quick Start" page I'm about to write will show RTK as the default, and we'll emphasize that elsewhere throughout the docs as they get rewritten.
There's also nothing we can do about the 5 million existing tutorials out there on the internet, and it's not like the core APIs would be _removed_. All those are still syntactically valid. Even if we shipped all these additional APIs as part of the core, people would have to look to see that they exist.
To stay on analogies, it's more like GNU and Linux.
Vanilla Redux on its own is like Linux without an userland, so you have to implement yourself.
Redux Toolkit is a proper Linux with GNU userland. It's ready to use, and people can even use each other's computers without reading through the source code!
It doesn't make a lot of difference for smaller projects, but the thing about Redux is that as soon as you have 20+ or 30+ people working on the same codebase you get a hodgepodge of different patterns and structures. Toolkit solves it.
Out of curiosity, anything specific that concerned you?
If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns in practices in our Style Guide docs page [2] that should result in simpler and easier to understand code.
[0] https://redux-toolkit.js.org
[1] https://react-redux.js.org/api/hooks
[2] https://redux.js.org/style-guide/style-guide