5 ms·
I don't think there's anything about React + Redux that is inherently slow, but I don't think it's as "idiot proof" as other frameworks out there. One app at my
by panopticon 7y ago
I don't think there's anything about React + Redux that is inherently slow, but I don't think it's as "idiot proof" as other frameworks out there. One app at my previous employer cargo-culted redux to the point where no component was allowed to have its own state. With its massive global state, every keystroke was painfully slow (thanks, redux-form).
- acemarke 7y agoAnd that is something we explicitly suggest that people _not_ do: 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... https://redux.js.org/faq/organizing-state#should-i-put-form-state-or-other-ui-state-in-my-store https://redux.js.org/faq/organizing-state#should-i-put-form-...
- fyfy18 7y agoI've seen a couple of apps that have the same anti-pattern. They have a connected component that is basically a global container of all other components. They don't do anything sophisticated with shouldComponentUpdate, so whenever something changes all child components (i.e. basically the whole app) is rendered again. On its own that isn't necessarily that bad, but combine that with form fields directly manipulating the Redux state (i.e. an action for every keypress) and it's easy to build an app that has poor performance.
- fourthark 7y agoSelecting only the needed data for each component should mitigate this, since react-redux automatically compares the selected data only. I will agree that it's too easy for components to watch too much of the state, but it's not necessarily wrong to have all the state in one tree.