3 ms·
I'll disagree with you on that last point. We specifically encourage that pattern - treating actions as "events" that any part of the reducer logic can respond
by acemarke 7y ago
I'll disagree with you on that last point. We specifically encourage that pattern - treating actions as "events" that any part of the reducer logic can respond to independently, rather than "setters".
Now, it's certainly true that _most_ actions will only be handled by a single slice reducer, but having many slice reducers responding to the same action is an incredibly useful pattern:
https://redux.js.org/faq/actions#is-there-always-a-one-to-one-mapping-between-reducers-and-actions https://redux.js.org/faq/actions#is-there-always-a-one-to-on...
- ratww 7y agoI do get the point of it being this way, but my problem with it is that it feels too much like magic, I think I just prefer to have the 1:1 relationship, like I already do with javascript functions or HTTP calls. But even leaving that aside, I still think that this specific "feature" is not worth the amount of boilerplate you need in most Redux apps, so it's not a nice tradeoff IMO :( I worked in some bigger apps, and before adopting ducks (and later a homebrew version of createSlice) we had some bugs caused by multiple reducers firing. I also think that it makes Flux/Redux a bit harder to explain
- Tade0 7y agoYou're not alone in this. Redux isn't complex, it's complicated - needlessly so. It takes just one look at its competitors to see this.