3 ms·
Redux isn't complex. It's a philosophy on how to manage state, and a few simple concepts to realize that philosophy (store, reducer, action, ...). It has nothin
by a_wild_dandan 7y ago
Redux isn't complex. It's a philosophy on how to manage state, and a few simple concepts to realize that philosophy (store, reducer, action, ...). It has nothing to do with React. Articles which effectively explain Redux by wading through the minutiae of a boilerplate app are anathema to that goal.
If anyone reading this wants to learn Redux, just read the getting started guide, or watch the co-creator's video series.[1] It's wonderful. If anyone just wants a TL;DW, here's mine:
1. The state of your application should be a tree. This tree is immutable. We call it a store.
2. Each branch of your state tree is generated by a pure function of the previous state and an action. We call these reducers.
3. The only way to effect change in your state is to dispatch actions. Dispatching action X triggers the root reducer for action X (which triggers the child reducers with action X, etc.), giving you the next state.
4. Subscribe to store changes with listeners.
That's really it. A general roadmap for managing state in your software. Has nothing to do with React. Or with user interfaces. Just a general approach to software state. You can roll your own in a few minutes for your use-case. If your use case happens to be a React UI or C# app, then yeah, reach for React-Redux or Redux.NET respectively.
But please, please don't learn Redux initially by looking at a React app that uses React-Redux. That's hardcore jumping the gun.
[1] https://egghead.io/lessons/react-redux-the-single-immutable-state-tree https://egghead.io/lessons/react-redux-the-single-immutable-...
- ratww 7y agoYes, Redux is easy. The problem is the incredible amount of boilerplate and repeated code in most tutorials and beginner projects, in the form of actions, switch statements and ALL_CAPS_STUFF. That boilerplate can easily take 10x more lines than "real" code in reducers, even in complex applications. Requiring three different files for each reducer, as in the article presented, is completely overkill, and it only makes sense when you're getting paid by the line of code. However, there are great solutions to avoid that. I'll echo the recommendation of createSlice: https://redux-starter-kit.js.org/api/createslice https://redux-starter-kit.js.org/api/createslice
- Izkata 7y ago> Requiring three different files for each reducer, as in the article presented, is completely overkill He only has one [0]. Note that the parent directory is "redux", not "reducer" - the actions and actionTypes are separate from the reducers, because there isn't a 1:1 relationship. This separation is because you could, for example, have a second reducer that listens to the same Add action as the one in this example - it doesn't need it's own action or actionType. [0] https://miro.medium.com/max/1383/1*JsqDyA2Wy_08GnHS6SMDmw.png https://miro.medium.com/max/1383/1*JsqDyA2Wy_08GnHS6SMDmw.pn...
- ratww 7y agoWhile you're technically correct, this is exactly what's overkill. Actions and ActionTypes are pure noise. And idk, having multiple reducers responding to the same action is a recipe for trouble.
- acemarke 7y agoI'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
- yawaramin 7y agoThat's all correct, but in common usage 'Redux' almost always means 'React-Redux', i.e. the integration of Redux into a React app. And given the OP, that should be clear in the context of my comment. And since we are talking about React-Redux, it is correct to say it is complex–as can plainly be seen in the OP.
- Izkata 7y agoI simplify 3 even further when introducing it to co-workers: Dispatching an action runs it on every reducer, which is why "type" is used it filter out the relevant ones.