Redux has the largest shift towards "negative opinion" out of all technologies. Did people just get fed up with the boilerplate or is there something else going on?
Redux is a bit like Java: it's possible to write well-designed software with it, but it's also gotten a reputation for being used by the sort of programmers who blindly apply "best practices" and create nine layers of AbstractFactoryGeneratorBeans for everything.
I suspect one factor in this is that if you know enough to apply Redux's patterns well, you probably also know enough to implement them yourself without bringing in a third-party NPM package. (Of course, not everyone will choose to do this --- maybe you like the Redux debugger UI or something --- but I think enough people do that it lowers the perceived average quality of codebases that do use Redux.) The library just doesn't do anything difficult in the way that, say, React's virtual-DOM diffing and reconciliation algorithms are difficult.
We were tasked with bringing an Angular/NgRx application up to date at work, and it was quite out of date. As the only person on the team with prior NgRx experience (it was quite minor though), I was volunteered to take responsibility for that portion of the project.
I quickly learned the previous devs had no idea what they were doing. They used the libraries but appeared to have no conception of what the actual pattern was, and so were getting essentially zero of the benefits.
I tried to make some piecemeal refactors, but I gave up on that approach. Everything was too tangled together, too reliant on other portions of the system, that I had no choice but to completely rewrite all aspects of the state management system.
It took me over a month, and I came away with a diminished opinion of NgRx. I think without context, it's good (but oh my, the boilerplate; I used to pooh-pooh people who complained about it but after thousands and thousands of lines of it, I have now joined their ranks). The problem is that ...
(a) it is likely significantly different than anything a standard team has used before, and highly complex;
(b) it provides ample footguns -- following the pattern is just as important as using the libraries, and this requires self-control that some don't have (not to mention actual knowledge of the pattern),
(c) therefore there seems to be a high likelihood of inexperienced teams building complex state management systems that don't provide any of the guarantees you want from NgRx and which become impossible to maintain.
I'm a data point of one, but that's been my experience with the Redux pattern/NgRx at work.
I was in a similar situation, and ultimately decided to reimplement the state management using NGXS. Fortunately the app was relatively small at that point, but I found that it held the developers hands a bit more, which lead to significantly more readable code.
Things can still get tangled up once you start using "ofActionDispatched" lifecycle handlers, but overall I found them to be far more manageable over time than NGXS.
I started to realize that it just doesn't make a lot of sense. It doesn't actually have a real concept of how to deal with asynchronous things (like, http requests). You have to use weird things like redux-thunk, or god forbid redux-saga.
The event system is basically synchronous, and just changes data which will be displayed in the UI. Why use the event abstraction and all the boilerplate that entails for synchronous code which doesn't really benefit from events? It feels like a cargo cult.
What it boils down to is any function which will at some point change the UI needs to be written weird, so that it takes the "dispatch" function and calls "dispatch(nextFunctionEvent)" instead of "nextFunction()".
Lots of developers always implemented their own half-ass systems to eliminate some boilerplate by automatically defining events from handlers and state or vice versa or some other combination of the above.
React hooks have basically eliminated it's niche, and none to soon!
Oh, please. The projects I've recently worked on used only Hooks instead of Redux. It was a nightmare to deal with. Files with endless amounts of `useSomething`, you'd need to dive through 4 levels of files to get to something useful.
Redux offers a ton of tooling and developer comfort if you get it right. And getting it right means having proper pull request reviews.
There's a lot of developer tooling (debugging tools), too, and a lot of middleware available to plug and play and GO.
If you're just using Hooks and the Reducer and Context APIs you're setting yourself up for a lot of headaches down the road.
Redux already makes use of those technologies, but wraps it in something easy to consume with a LARGE community for support.
Not using Redux is setting yourself up for failure, in my opinion. I've seen it happen too many times in the past year...
Thunks are hardly "weird". The thunk middleware is only about 12 lines long, and it's just a way to let you write arbitrary code that has access to `dispatch` and `getState` without being tied to a specific store instance.
Thunks are our recommended standard way to write async logic in Redux apps [0], and our new official Redux Toolkit package [1] automatically sets up thunks by default as part of the store configuration.
Sagas are incredibly powerful, but most apps don't need them [2]. They're most useful when you need complex "background thread"-like behavior.
And no, Redux is definitely _not_ eliminated or replaced by hooks [3] [4].
There's been a lot of reasons for a shift in opinions over the last few years:
- Redux is well past the initial burst of enthusiasm in the "hype cycle"
- As you mentioned, there are a number of common concerns expressed by a lot of folks, most of which revolve around "boilerplate"
- There are now a wider variety of other options that overlap with ways you'd use Redux: React's Context and Hooks APIs, MobX, GraphQL / Apollo Client, etc. These don't completely replace Redux, but they do overlap enough that there's not as much _need_ to choose Redux for everything.
- And, frankly, Redux _has_ been overused in a number of cases. Folks assume you _have_ to use Redux with React, sometimes because a senior dev told them so, because they saw yet another tutorial that pairs them together, or because it was asked for in a job listing.
Now, Redux is definitely not dead or dying. My own estimates are that around 50% of React apps are using Redux, and the overall total download trends are still increasing. But, it's also true that the market share will continue to spread out a bit over time.
I talked about these aspects in my Reactathon 2019 talk on "The State of Redux" [0] and my post "Redux - Not Dead Yet!" [1].
Besides all that, we're doing a lot of work to make it easier for folks to learn and use Redux.
- We have a new official Redux Toolkit package [2] [3]. It 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, and the feedback from folks who have adopted it has been amazingly positive.
- We are currently working on a major rewrite of the Redux core docs [4]. As part of that, we've already added a new "Style Guide" page [5] with our recommended best practices and guidelines for writing good Redux code, like structuring files as "feature folders" or "ducks", modeling actions as "events" instead of "setters", and so on. We're also going to completely redo all the tutorials and examples to show easier patterns to work with, drop outdated references to concepts and terms like "Flux" and "container components", and emphasize use of Redux Toolkit as the standard way to write Redux apps.
- Our new React-Redux hooks API [6] makes it a lot easier to work with Redux data in React components compared to the standard `connect` API, especially if you're using TypeScript.
So yeah, there are some repeated waves of annoyance with Redux that pop up on social media every so often, but there's also a ton of folks still using and learning Redux. My goal is to continue to make it easier for Redux users of all levels to use Redux.
How do you feel about runtime type checking and model validation in Redux? Will that ever be a thing? This is the killer feature that made me abandon it for MobX State Tree.
Not sure what MST does there, but that's not something that would ever be built into the Redux core. The store API is complete as-is. The only changes we're making there are porting it to be written directly in TypeScript.
It's usage is probably being replaced with GraphQL + Apollo/Relay since the need for FE app state is reduced when you no longer need to make multiple round trip requests. Also Apollo (possibly Relay?) offer local state management too.
That would explain drop in use/popularity, but actually Redux is raising in usage, while sharply dropping in the other dimension towards "negative opinion".
