I pressed Pete on what he actually meant by that in the replies [0]. Eventually he listed some specific concerns:

- The React ecosystem has fragmentation because there's many ways to do things, and he feels someone needs to start narrowing down suggestions to reduce confusion.

- There was an article going around on "Why I'll Never Use React for Enterprise Apps Again", and half of the problems listed in the article were about Redux and React ecosystem related issues instead of React itself, so Pete's upset about that

- Pete feels opinionated data fetching tools and explicit state machines solve some use cases better

- Pete thinks it's too hard to dynamically code-split Redux logic

So, those are valid technical points that can be discussed in detail. But those are also a very far cry from "NEVER EVER USE REDUX!", and I'm really not sure how you jump from "one article said they had trouble migrating their code from `connect` to hooks and they aren't happy with Redux-Saga" to "NEVER USE REDUX" either.

I actually pointed out that we have a new upcoming "RTK Query" API that's in alpha right now [2] that drastically simplifies data fetching and caching for Redux, and Pete said later in that thread he thought it looked impressive. He also said he appreciates the work put into Redux Toolkit and our docs updates.

So yeah, Pete said that, but as usual there's a lot more nuance in the later discussion that should be highlighted rather than the clickbait-y initial tweet.

[0] https://twitter.com/acemarke/status/1365824897210064897

[1] https://betterprogramming.pub/i-almost-got-fired-for-choosin...

[2] https://rtk-query-docs.netlify.app

I've found this works so much better than reaching for state management libraries off the bat. Most of the time it's overkill and the complex state transforms really only affect a few parts of the application, in which case useContext and useReducer can help immensely.

Learning the built-in React features goes a longer way than specific state management libraries if you're starting out. I'm really wary of anyone selling a specific set of libraries as being the way for beginners to go, unless they're tackling apps that have very specific state management needs.

FWIW, I completely agree that people should focus on learning React itself first, and then pick up other libraries (like Redux) later, and we specifically make that recommendation in the Redux docs.

That's also the kind of advice I want to have in this new "Community Tools" resource site. At the same time, this site _is_ intended to list common tools in use in the ecosystem and when it _might_ make sense to use them.

This is more commentary on the "the best React state management setup for you is..." comment above than the site itself. I fundamentally take issue with there being a "best" solution for state management, especially targeted at people starting out. The various libraries can do great things for different apps, but the answers as to what works best for a given situation tend to be nuanced.

There can’t be a universal best solution to state management. Sometimes your requirements are so simple that using a library is overkill and basic JS is fine. Sometimes your requirements are so complicated that well-known libraries like Redux and MobX aren’t enough, and if you’re going to implement something more comprehensive anyway then the extra dependency might not be helpful. In between, there is a scale where different strategies might work best. A site that helps less experienced developers to figure out where their needs fall on the spectrum and which strategies might work well for them seems like a helpful idea.

I agree, once again my original comment is in response to a comment on here that I'm replying to and not the linked article. I myself would find a lot of utility in a site that compares all the different approaches.

I was commenting in support of your position. Sorry if that wasn’t clear!

I take the point that "best" isn't completely objective, but it's also important for people with experience to help those learning the ecosystem. The state management players differ in philosophy and quality. I’m not sure Redux is abstractly the best state management pattern, but practically it’s a very high quality library with native-app quality tooling.

Completely agree that anyone learning React should learn the built in patterns first. My point was that if your app is becoming meaningfully more complicated because you are working around the limits or useState and useContext, you should not hesitate to learn and use Redux, even in 2021.

Good rule of thumb is to disregard any statement like "Literally never ever ... under any circumstances" irregardless of the supposed reputability of the person saying it. Its either purposely meant to be a hot take to rile people up or its lacking nuance.

As other comments have mentioned, he has valid concerns and some opinions about what a preferable architecture looks like but for whatever reason he chose not to lead with that.

Redux became a thing because of Dan Abromov's impressive tutoring and documenting skills early on and due to acemarke being a good leader after he left.

It's a nice pattern but in an artistic sense.

Changing UI state 10 years back:

state.totals = 100;

Changing state today:

1. Call an action creator

2. Dispatch an action to the reducer

3. Switch by action type

4. Apply action on state

5. Return new state

So imho the problems start right at the bottom - the extreme verbosity and the redundancy.

I'm not saying anything about the actual tools here. I have an opinion of course but that's not relevant here. What I'm saying is most technical decisions require nuance and thought. If someone is presenting a thought without any room for nuance, it probably doesn't stand up to scrutiny. What the frontend community needs is more honest and nuanced appraisals of tech and less cargo culting.

Most people take umbridge because Redux was cargo culted in the first place, cargo culting against it isn't that helpful. I think the website shared in this post is a great approach. Show everyone the options and let them decide what solution fits their problem.

That does not sound like you are up-to-date with what the official redux tutorials currently recommend for writing modern redux. https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

Also, two-way-data-bindings like just `state.totals` work when you're just re-rendering your whole app on every frame, but as soon as you get away from that, there will always be either some "observing" or "signalling" involved to trigger rerendering of the correct parts of your application. Redux goes the "signalling" way, MobX goes the "observing" way, both have their benefits and drawbacks.

> That does not sound like you are up-to-date with what the official redux tutorials currently recommend for writing modern redux. https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

--- start quote ---

import { combineReducers } from 'redux'

import { createStore, applyMiddleware } from 'redux'

import thunkMiddleware from 'redux-thunk'

const composedEnhancer = composeWithDevTools(applyMiddleware(thunkMiddleware))

import { createSlice } from '@reduxjs/toolkit'

...createSlice will automatically generate action creators

--- end quote ---

It's.... it's not better in any way?

> Redux goes the "signalling" way, MobX goes the "observing" way, both have their benefits and drawbacks.

I like Svelte's approach. Where they figure out which things are being observed or changed at compilation/transpilation time and generate code for that case specifically.

That page introduces one tool after another, replacing all those external tools with the officially recommended Redux Toolkit that wires all of them up for you.

In the end you are left with only

`import { configureStore, createSlice } from '@reduxjs/toolkit'`

> That page introduces one tool after another, replacing all those external tools with the officially recommended Redux Toolkit

Perhaps. As person who's never used thunks or, really, half of those tools in conjunction with Redux, this tutorial is quite confusing.

> In the end you are left with only import { configureStore, createSlice } from '@reduxjs/toolkit'

The final code on the page is literally

  import {
    createSlice,
    createSelector,
    createAsyncThunk,
    createEntityAdapter
  } from '@reduxjs/toolkit'

The page doesn't really address the issue of verbosity and the flow as described in the original comment. It just hides some of it behind some facades with autogenerated accessor functions (so, even more levels of abstractions).

Yes, the entire point of that page is:

- You've gone through this whole tutorial sequence and should now understand how to write all this Redux logic "by hand" and why these standard Redux usage patterns exist

- Now, here's how Redux Toolkit abstracts and simplifies those exact same patterns, so that you can do the same thing with less code, but you understand what those abstractions are doing for you internally.

What's one good reason why JS proxies (which let you listen to "state.totals = 100") aren't a cleaner solution to trigger a rerender?

There's no need to rerender the whole frame - will be happy to provide an example on request.

That would be the "observing" approach I described.

The upside of an action-based (signalling) approach is that you have a better time separating concerns as actions (if used correctly) represent intent, so your component emits an event and the state acts accordingly, removing state logic from your representational components. Might also be a lot easier to see in the DevTools what happened when and why.

Of course not every app needs a pattern like that, that's why I said both approaches are valid.

My point is that the action-based approach you describe is extremely verbose for very little gain. Most apps don't need it, yet that's what Redux forces you to do.

Regarding DevTools, it's just as easy to make it work with "observing".

Also, I'm not saying you should write state changes and data fetching in the UI components. By all means write them under actions/services whatever. I'm complaining about the complexity around effecting that change.

It doesn't seem verbose to me. Have you looked into those docs above? You define a reducer and an action creator is automatically generated. String action types are an implementation detail. No manual immutable state modification, as immer is baked in. Modern redux is maybe 20% of what you might be imagining if you only know legacy redux.

It's not much more code than writing a function, but other reducers of your state can suddenly act upon the same action, you can trigger side effects using middleware and of course watch stuff "by intent" and not "there was a modification" in the devtools. All while keeping everything separated pretty well.

More steps can be good if they clarify thinking (Typescript) and make code more intuitive. Complex apps have complex state and Redux handles that really well. It might no be needed for a TODO list tutorial, but comments like these are what prevented me learning Redux (I was like wtf are dispatch, action, thunk - seems lame) when it's actually a great tool that often reduces complexity.

Also, with action factory, step 1 can be automated.

Note that our official Redux Toolkit package is the recommended approach for writing Redux logic:

https://redux-toolkit.js.org

https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

It doesn't eliminate the "dispatch actions" concept, because that's core to how Redux works. But, it does simplify the vast majority of your Redux logic considerably.

What about something like zustand? https://zustand.surge.sh/