5 ms·

> If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? Sadly

> If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? Sadly it seems that's mainly been cargo-culted. It's not the case that React+Redux is the equivalent to say Angular, but by some unfortunate accident due to Facebook's announcement of Flux, and then the hype around Redux as a 'better Flux', people started assuming React+Redux is what is needed to build a React app. Meanwhile Dan Abramov, Redux creator says [1]: > Flux/Redux is meant for big apps with complex nested UIs that have many independent parts but share common caches of data. That's not "every semi-complex React app". In most "semi-complex React apps", most state can be derived from the route (e.g. react-router) or is relatively local. Redux is not required. [1] https://twitter.com/dan_abramov/status/732719257579065345 https://twitter.com/dan_abramov/status/732719257579065345

ilovecaching 8y ago
Agreed. Cargo culting is the main issue. The solution is to try and remain unbiased, and not look for direct synonyms between two very distinct approaches to managing user interfaces.
- olfactory 8y ago
  Well, FWIW js is not the most friendly language for functional programming. I'd argue that the trend toward immutable.js and redux occurred partly because rest/spread syntax was/is relatively confusing, and so immutable patterns without a library feel less elegant until one really groks the somewhat visually opaque semantics of the rest/spread syntax. Redux also offered a simple approach to the "action bus" idea from Flux, but omitted first class async support, etc. React itself also somewhat overlooked async patterns, which created the idea that their absence was by design and so an additional (opinionated) library was appropriate. In sum I'd argue that React actually fights against js quite a bit and that it will truly come into its own once reason gets more mindshare. For those of us who invested heavily in react as all this was becoming clear (and being ironed out) I hope we learned enough to allow better decision making in the future. Also, React has a few "on by default" performance enhancements that are a bit conceptually confusing and create something of a mismatch with the functional approach. But still it's difficult (and unpleasant) to imagine the world without React.
atombender 8y ago
There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise some sort of longevity. We also need to pick tools where best practices and idioms have been established. To do this we have to trust someone else's opinion and try to gauge which solutions have the best prospects. This means not just evaluating software based on its own technological merits, but also listening to what "the community"/"the industry" seems to be rallying around; you don't want to be stuck using a library that nobody is maintaining, just as you don't want to be stuck using something that's just badly designed. When we started using React, there was no state management framework available, and everything was handled somewhat ad-hoc. Then Facebook described Flux, and we realized they were onto something, so we started using their patterns, with some simplifications where theirs seemed overly complicated. Then Redux came along and seemed like a better way to do things. At each point there was uncertainty about what best practices and "idiomatic" solutions would turn out to be, because the technology was immature. I don't think anyone was cargo-culting. It was just that a lot of people were busy trying to create things, and when there isn't clear guidance, and the alternative is going back to Backbone or jQuery or something, then you just forge ahead, trying to do fit the pieces together.
- allover 8y ago
  But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened? Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.
ppseafield 8y ago
I remember when I first started to try and learn React there was only a handful of words and a vague diagram from Facebook about its Flux architecture. And after that there were many, many similar state management libraries. That some in the community picked a smaller one that had in-depth documentation and emphasized stateless / functional style programming is not terribly surprising. IIRC there were a lot of comments about having to pass props to children constantly (without using a state management library). Seems like it's a lot easier to not use a state management library now that an official, non-experimental Context API exists. But remember, this was only added a few years later.
jbergens 8y ago
Also, MobX is for most devs easier to understand and use than Redux and more similar to Vue and Angular. I think most small react projects should start with no external state management or mobx and only switch if they need it. Unless they already know redux very well and think it suits their project.
Globz 8y ago
Just to add some weight to your opinion about Redux being cargo-culted take a look at this video https://youtu.be/S6lwJ6Rixnc?t=6m https://youtu.be/S6lwJ6Rixnc?t=6m

ilovecaching 8y ago

Agreed. Cargo culting is the main issue. The solution is to try and remain unbiased, and not look for direct synonyms between two very distinct approaches to managing user interfaces.

olfactory 8y ago
Well, FWIW js is not the most friendly language for functional programming. I'd argue that the trend toward immutable.js and redux occurred partly because rest/spread syntax was/is relatively confusing, and so immutable patterns without a library feel less elegant until one really groks the somewhat visually opaque semantics of the rest/spread syntax. Redux also offered a simple approach to the "action bus" idea from Flux, but omitted first class async support, etc. React itself also somewhat overlooked async patterns, which created the idea that their absence was by design and so an additional (opinionated) library was appropriate. In sum I'd argue that React actually fights against js quite a bit and that it will truly come into its own once reason gets more mindshare. For those of us who invested heavily in react as all this was becoming clear (and being ironed out) I hope we learned enough to allow better decision making in the future. Also, React has a few "on by default" performance enhancements that are a bit conceptually confusing and create something of a mismatch with the functional approach. But still it's difficult (and unpleasant) to imagine the world without React.

atombender 8y ago

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise some sort of longevity. We also need to pick tools where best practices and idioms have been established. To do this we have to trust someone else's opinion and try to gauge which solutions have the best prospects. This means not just evaluating software based on its own technological merits, but also listening to what "the community"/"the industry" seems to be rallying around; you don't want to be stuck using a library that nobody is maintaining, just as you don't want to be stuck using something that's just badly designed. When we started using React, there was no state management framework available, and everything was handled somewhat ad-hoc. Then Facebook described Flux, and we realized they were onto something, so we started using their patterns, with some simplifications where theirs seemed overly complicated. Then Redux came along and seemed like a better way to do things. At each point there was uncertainty about what best practices and "idiomatic" solutions would turn out to be, because the technology was immature. I don't think anyone was cargo-culting. It was just that a lot of people were busy trying to create things, and when there isn't clear guidance, and the alternative is going back to Backbone or jQuery or something, then you just forge ahead, trying to do fit the pieces together.

allover 8y ago
But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened? Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.

ppseafield 8y ago

I remember when I first started to try and learn React there was only a handful of words and a vague diagram from Facebook about its Flux architecture. And after that there were many, many similar state management libraries. That some in the community picked a smaller one that had in-depth documentation and emphasized stateless / functional style programming is not terribly surprising. IIRC there were a lot of comments about having to pass props to children constantly (without using a state management library). Seems like it's a lot easier to not use a state management library now that an official, non-experimental Context API exists. But remember, this was only added a few years later.

jbergens 8y ago

Also, MobX is for most devs easier to understand and use than Redux and more similar to Vue and Angular. I think most small react projects should start with no external state management or mobx and only switch if they need it. Unless they already know redux very well and think it suits their project.

Globz 8y ago

Just to add some weight to your opinion about Redux being cargo-culted take a look at this video https://youtu.be/S6lwJ6Rixnc?t=6m https://youtu.be/S6lwJ6Rixnc?t=6m