4 ms·
That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state
by brhsagain 4y ago
That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state. Then they use something like Redux because it provides "structure" and has lots of stars on Github.
Incidentally, I have to agree with the author directionally on this point. Redux makes codebases such a pain in the ass to work with. Every new change you want to make to the store, you have to make about five changes across five different files. When you're working on a new feature you spend most of your time just wrestling with Redux, creating an action type, creating an action creator, creating a reducer, importing/exporting all this shit, blah blah blah. Then a new engineer who wants to figure out what the code is actually doing has to trace through the action, then the action creator, then the reducer, blah blah. This is before you throw in stuff like epics and run API calls through your action/reducer pipeline. It is no wonder productivity per capita in tech is so low.
- flippinburgers 4y agoRedux toolkit does exist.
- TheBigSalad 4y agoI hated redux until I started using this.
- acemarke 4y ago> Every new change you want to make to the store, you have to make about five changes across five different files This has never actually been a requirement to use Redux. Admittedly, having separate folders and files by type _was_ a pattern that was shown in the docs originally ( `reducers/todos.js`, `actions/todos.js`, `constants/todos.js`, etc), but even in the early days the "Ducks" pattern of "put all the logic for a feature in one file" was a thing that you could do. Today, we specifically teach "slice/ducks files" as the standard approach [0] [1], and Redux Toolkit's `createSlice` API makes it trivial to do that - just write the reducers, export the matching auto-generated action creators, and you're done. > throw in stuff like epics We've actually been advising _against_ using both sagas and epics for side effects for years now, and especially against using them for basic data fetching. Today, Redux Toolkit's "RTK Query" data fetching and caching API is a complete solution for caching server state on the client, and we also recently shipped a new "listener" middleware that is a simpler alternative to sagas and epics for other reactive side effects. [0] https://redux.js.org/tutorials/essentials/part-2-app-structure#creating-slice-reducers-and-actions https://redux.js.org/tutorials/essentials/part-2-app-structu... [1] https://redux.js.org/style-guide/#structure-files-as-feature-folders-with-single-file-logic https://redux.js.org/style-guide/#structure-files-as-feature...
- brhsagain 4y agoI'm not totally convinced this makes things better. To me, the problem with Redux is the whole act of having a ritual ceremony around every mutation you want to make to your state. To put things in perspective, I'm currently building an IDE from scratch "game development" style, in that I have a global "world" state that gets reflected in the rendered UI 144 times a second. So it's a similar paradigm to React -- except when I want to modify state, I just do it. Like I literally just mutate the variable by writing to it. Sometimes I do a particular mutation in many places and at that time I will pull it out into a function, but in general writing to state is not this enshrined procedure. I could not fathom developing this thing while having to create a new slice/duck for every state change I want to make. I guess some people see the enshrined procedure as a feature and not a bug, and it is possible you could weigh the benefits of Redux's features against the cost in engineering time and decide it's worth it.. but it doesn't seem like this tradeoff is being consciously made and analyzed. It seems more like everyone just assumes they need something like Redux the moment they have global state.