4 ms·

> If any react noobs are reading this, the best React state management setup for you is Redux+Immer. React noobs should just stick to React's own useState and

by jeswin 6y ago

> If any react noobs are reading this, the best React state management setup for you is Redux+Immer. React noobs should just stick to React's own useState and useContext hooks. There are issues with it, but it's not as bad. Here's what Pete Hunt from the original React team said last week: "Literally never ever use Redux on a new project under any circumstances. Even if it’s what the team knows." [1] 1: https://twitter.com/floydophone/status/1365824299060273153?s=19 https://twitter.com/floydophone/status/1365824299060273153?s...

acemarke 6y ago
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 https://twitter.com/acemarke/status/1365824897210064897 [1] https://betterprogramming.pub/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c https://betterprogramming.pub/i-almost-got-fired-for-choosin... [2] https://rtk-query-docs.netlify.app https://rtk-query-docs.netlify.app
dsego 6y ago
What about something like zustand? https://zustand.surge.sh/ https://zustand.surge.sh/
ericwood 6y ago
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.
- acemarke 6y ago
  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.
  - ericwood 6y ago
    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.
    - Chris_Newton 6y ago
      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.
richeyryan 6y ago
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.
- jeswin 6y ago
  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.
  - phryneas 6y ago
    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-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.
    - jeswin 6y ago
      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.

by jeswin 6y ago

acemarke 6y ago

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 https://twitter.com/acemarke/status/1365824897210064897 [1] https://betterprogramming.pub/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c https://betterprogramming.pub/i-almost-got-fired-for-choosin... [2] https://rtk-query-docs.netlify.app https://rtk-query-docs.netlify.app

dsego 6y ago

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

ericwood 6y ago

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.

acemarke 6y ago
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.
- ericwood 6y ago
  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.
  - Chris_Newton 6y ago
    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.

richeyryan 6y ago

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.

jeswin 6y ago
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.
- phryneas 6y ago
  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-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.
  - jeswin 6y ago
    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.