5 ms·

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 o

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.

atombender 8y ago
Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing. I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.
- allover 8y ago
  > Can we blame all the bloggers who take upon themselves to explain what the best practices is? It's not really about blaming bloggers. It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all-the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious. > The good design is to be found in Relay and GraphQL. Nah again, good example to question what you read/hear. GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.
jakelazaroff 8y ago
The official docs originally described React as "the V in MVC" [1], so the assumption about needing another layer to handle state and business logic didn't come from nowhere. The claim isn't that there's no cargo cult around the React ecosystem — but not everyone writing React code is approaching it with experience, which means they try to pick up best practices from other people. That's not "cargo culting"; it's a reasonable thing to do when you have to solve a problem you don't know how to solve! Ultimately, people aren't being "tricked" into using these tools. They proliferate because they solve real problems people have, and a lot of people would rather work with a popular and well-documented solution (with known advantages and drawbacks) than trying to forge their own path and seeing how it goes. [1] https://github.com/facebook/react/pull/7012 https://github.com/facebook/react/pull/7012
_hardwaregeek 8y ago
Could you provide a source for the maintainers of redux-form admitting that Redux was a poor fit for forms? I'm inclined to agree and am kind of interested to see their reasons.
- allover 8y ago
  Yep, sorry I should have included the reference. This post is by the redux-form creator, in which he states why it was a bad idea, and announces its 'spiritual successor': https://codeburst.io/final-form-the-road-to-the-checkered-flag-cd9b75c25fe https://codeburst.io/final-form-the-road-to-the-checkered-fl... > Also, everyone high up in the React community, including both inventors of Redux [1], say that Redux is not the best place to keep form data. Oops. [1] https://github.com/reactjs/redux/issues/1287#issuecomment-175351978 https://github.com/reactjs/redux/issues/1287#issuecomment-17...
  - acemarke 8y ago
    Now, it _does_ depend on your use case. An isolated login form? Yeah, no point keeping that in Redux - it's not being shared, it's not being persisted, there's no real need to track the history of changes. But, there are certainly situations where you might want to keep some form data in Redux. As a specific example from my own app: we show some polylines on a 3D globe, and allow the user to edit them. We need to be able to live-update the point locations and labels on the globe as the user edits them, allow resetting edits, and still be able to show the original values elsewhere in the UI. Keeping all that data in Redux makes it easy to do so. The Redux FAQ has a list of suggested rules of thumb for deciding what state should go in Redux: https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... .
    - mosdl 8y ago
      You can achieve all of that with a singleton that is shared and some events (and do some of your own batching). No need for another dependency and you save bloat size.

atombender 8y ago

Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing. I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.

allover 8y ago
> Can we blame all the bloggers who take upon themselves to explain what the best practices is? It's not really about blaming bloggers. It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all-the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious. > The good design is to be found in Relay and GraphQL. Nah again, good example to question what you read/hear. GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.

jakelazaroff 8y ago

The official docs originally described React as "the V in MVC" [1], so the assumption about needing another layer to handle state and business logic didn't come from nowhere. The claim isn't that there's no cargo cult around the React ecosystem — but not everyone writing React code is approaching it with experience, which means they try to pick up best practices from other people. That's not "cargo culting"; it's a reasonable thing to do when you have to solve a problem you don't know how to solve! Ultimately, people aren't being "tricked" into using these tools. They proliferate because they solve real problems people have, and a lot of people would rather work with a popular and well-documented solution (with known advantages and drawbacks) than trying to forge their own path and seeing how it goes. [1] https://github.com/facebook/react/pull/7012 https://github.com/facebook/react/pull/7012

_hardwaregeek 8y ago

Could you provide a source for the maintainers of redux-form admitting that Redux was a poor fit for forms? I'm inclined to agree and am kind of interested to see their reasons.

allover 8y ago
Yep, sorry I should have included the reference. This post is by the redux-form creator, in which he states why it was a bad idea, and announces its 'spiritual successor': https://codeburst.io/final-form-the-road-to-the-checkered-flag-cd9b75c25fe https://codeburst.io/final-form-the-road-to-the-checkered-fl... > Also, everyone high up in the React community, including both inventors of Redux [1], say that Redux is not the best place to keep form data. Oops. [1] https://github.com/reactjs/redux/issues/1287#issuecomment-175351978 https://github.com/reactjs/redux/issues/1287#issuecomment-17...
- acemarke 8y ago
  Now, it _does_ depend on your use case. An isolated login form? Yeah, no point keeping that in Redux - it's not being shared, it's not being persisted, there's no real need to track the history of changes. But, there are certainly situations where you might want to keep some form data in Redux. As a specific example from my own app: we show some polylines on a 3D globe, and allow the user to edit them. We need to be able to live-update the point locations and labels on the globe as the user edits them, allow resetting edits, and still be able to show the original values elsewhere in the UI. Keeping all that data in Redux makes it easy to do so. The Redux FAQ has a list of suggested rules of thumb for deciding what state should go in Redux: https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... .
  - mosdl 8y ago
    You can achieve all of that with a singleton that is shared and some events (and do some of your own batching). No need for another dependency and you save bloat size.