4 ms·

In actual use I've seen that Redux apps often wind up with a lot of accidental data dependencies that probably wouldn't have happened without a centralized stor

In actual use I've seen that Redux apps often wind up with a lot of accidental data dependencies that probably wouldn't have happened without a centralized store. For example devs will lazily use a "currentUser" key in the store for all kinds of unrelated stuff and subtle bugs creep in. Another common problem with Redux is memory issues because various components don't clear their data out of the store when they're unmounted. Redux has some nice features but at this point I recommend people avoid it until they start to suffer from some of the problems it was designed to solve. You can get pretty far with a lot less complexity by use using local component state in vanilla React.

davnicwil 8y ago
I absolutely agree with you and that's been my experience too, I've seen exactly those problems in both my own code and others' code. It took me personally many iterations over various projects to learn the boundaries of where redux makes more sense and where component state makes more sense. That's perhaps the biggest actual inherent problem with redux, that it may implicitly encourage everything to be in the one single centralised store, for newcomers. That's a hard problem to solve, though I'm fairly certain Dan Abramov and the other maintainers have tried to make it clear that this, and using redux at all in simple apps, is usually a mistake.
- cageface 8y ago
  Yeah my approach now is to use Redux only for state that's shared among a bunch of components. Local state is fine and a lot simpler for things that aren't globally interesting.
- acemarke 8y ago
  Hi, I'm a Redux maintainer. The Redux FAQ specifically has an entry with rules of thumb to help decide when it makes sense to keep a given piece of state in Redux [0]. I do agree that the "Single Source of Truth" principle [1] is probably over-interpreted, and maybe needs some caveats somehow. That said, it's tough to simultaneously say "here's the basics of how Redux works", "here's the ideas behind why you _should_ use Redux", and also try to tell people when to _not_ use Redux. We're currently planning a revamp of the Redux docs content [2]. I'd appreciate it if you could fill out this survey on how we can improve the docs structure [3], or leave a comment in that issue thread with some suggestions. [0] https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-react-s-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... [1] https://redux.js.org/introduction/three-principles https://redux.js.org/introduction/three-principles [2] https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/2590 [3] https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYMK0YoEgALfAK2qQ0mOj1_ibKv2qDTuQ/viewform https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYM...
chrisweekly 8y ago
... or try MobX

davnicwil 8y ago

I absolutely agree with you and that's been my experience too, I've seen exactly those problems in both my own code and others' code. It took me personally many iterations over various projects to learn the boundaries of where redux makes more sense and where component state makes more sense. That's perhaps the biggest actual inherent problem with redux, that it may implicitly encourage everything to be in the one single centralised store, for newcomers. That's a hard problem to solve, though I'm fairly certain Dan Abramov and the other maintainers have tried to make it clear that this, and using redux at all in simple apps, is usually a mistake.

cageface 8y ago
Yeah my approach now is to use Redux only for state that's shared among a bunch of components. Local state is fine and a lot simpler for things that aren't globally interesting.
acemarke 8y ago
Hi, I'm a Redux maintainer. The Redux FAQ specifically has an entry with rules of thumb to help decide when it makes sense to keep a given piece of state in Redux [0]. I do agree that the "Single Source of Truth" principle [1] is probably over-interpreted, and maybe needs some caveats somehow. That said, it's tough to simultaneously say "here's the basics of how Redux works", "here's the ideas behind why you _should_ use Redux", and also try to tell people when to _not_ use Redux. We're currently planning a revamp of the Redux docs content [2]. I'd appreciate it if you could fill out this survey on how we can improve the docs structure [3], or leave a comment in that issue thread with some suggestions. [0] https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-react-s-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... [1] https://redux.js.org/introduction/three-principles https://redux.js.org/introduction/three-principles [2] https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/2590 [3] https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYMK0YoEgALfAK2qQ0mOj1_ibKv2qDTuQ/viewform https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYM...

chrisweekly 8y ago

... or try MobX