6 ms·

This article isn't really a comparison. It's almost completely dedicated to explaining Redux. In fact the complexity of explaining even this simple app with jus

This article isn't really a comparison. It's almost completely dedicated to explaining Redux. In fact the complexity of explaining even this simple app with just a couple of components, should serve as a reminder of how complex Redux is. The only real mention of the plain ReactJS version is near the end, where it actually links to another article which compares ReactJS and Vue.

nine_k 7y ago
I personally think that redux is very simple when you just explain its key idea. It only becomes complex when people trying to show a "cultured" way to write a large redux/react app bring in a ton of containers, controllers, action classes with methods for various auxiliary conveniences, etc. Even the example in redux's own docs is unnecessarily complex. This is not how you explain things. For an explanation, i'd use a single file, with 2-3 actions, using strings (or an enum) to denote actions, with a reducer right next to renderer, and a single-function react component. Then the data flow becomes apparent, and the usefulness of redux for keeping state within the unidirectional loop becomes also apparent. After getting the key idea, the reader will have an easy time understanding tools built around it, ways to fold up the boilerplate, etc. A react/redux app can be very compact and approachable, even when the logic is complex.
- acemarke 7y ago
  Yep, this is something I plan to do in our upcoming docs revamp. The initial tutorials will drop action creators, drop `const ADD_TODO = "ADD_TODO"`, drop splitting things into multiple files, etc. And yeah... a lot of the stuff normally associated with Redux is _intended_ as a "large project maintainability best practice" kind of thing.
  - gimboland 7y ago
    Mark, your writings have really helped me to understand the redux landscape (inasmuch as I do), so I'd be curious to know what you think of this, if you've seen it: https://www.youtube.com/watch?v=JmnsEvoy-gY https://www.youtube.com/watch?v=JmnsEvoy-gY ("Good Action Hygiene with NgRx", Mike Ryan, NGConf April 2018) The context is ngrx but the territory is familiar. Two things struck me in particular: one (the key point of the talk) is the idea that actions should be named as effects not intentions. The other (which I loved) is the idea of having action types that look like (say) "[Todo List Page] Add Todo Clicked" rather than "ADD_TODO" — it certainly makes the history more legible in redux-devtools. (I'm unsure how to name my consts then, though; I'm going with TODO_LIST_PAGE_ADD_TODO_CLICKED but it's very verbose; in the video it looks like he's not bothering with consts at all, and is just using the strings directly at dispatch and reduce time, and maybe there's something in that — the strings are specific enough that there'd be no scope for confusion, I guess.) Just wondered what you thought of all this? I've read your idiomatic redux series, but maybe your thoughts have moved on since then...
    - acemarke 7y ago
      I have that talk bookmarked to watch, but my bookmarks queue is like 600+ deep at this point :) Just going by your summary: Yeah, I do find it interesting how some different parts of the community have chosen to format their action strings differently. Redux itself literally doesn't care, of course - the only requirement is that `action.type` not be undefined. As I said in "The Tao of Redux, Part 1: Implementation and Intent" [0], one of the main intents behind Redux is that the action log should be a literally readable history of what's going on in your app with semantic meaning behind each name. You _could_ have a single `"SET_DATA"` action, but that doesn't tell me anything about what's going on. The Redux docs originally went with the SCREAMING_SNAKE_CASE string format just because that's the common programming world convention for constant values. The naming in the docs also tends towards matching how you would name the action creator, ie, `"TOGGLE_TODO"` -> `toggleTodo()`. Those are perfectly legitimate choices to make, but definitely not the only possible ways to do it. I've seen plenty of other variations over the years, usually in the form of some "domain" string + the "event" name. For Redux Starter Kit, we've gone with a '/'-separated string, such as `"todos/addTodo"`. The end user is still supplying both parts (via the slice `name` field and the user-defined reducer function name). So, the Angular-ish convention of `"[Some Domain] Some Event"` is perfectly fine, and very readable. Either way, it doesn't matter what you actually name the _variable_ that points to that action type. One of the most interesting variations I've seen on this is Slack, which apparently uses entire _sentences_ as their action types, each including a unique numeric ID [1]. Finally, yes, we would generally recommend treating actions semantically as "events in the app", not "setters at a distance". Again, the Redux store itself doesn't care, but the "events" mental modeling promotes dispatching fewer total actions and having multiple reducers independently responding to a given action [2]. We'll emphasize this more in the upcoming docs revamp. Glad to know my writing has helped! Lemme know if you've got any other questions. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://twitter.com/erikras/status/1153350835738468363 https://twitter.com/erikras/status/1153350835738468363 [2] 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...
      - 7y ago
- untog 7y ago
  For me the problem with Redux is not that it’s complicated, it’s that it’s wildly verbose and adds a huge layer of misdirection to an app. Some apps are complex enough that they need this. In my experience, a lot of Redux apps really aren’t all that complicated, and people have used Redux because it’s The Thing To Do.
  - oijoihodsf 7y ago
    I think that's the problem with demonstrating Redux, no? You start reaping the benefits when you need a state machine to manage complexity of your application. Thus, to demonstrate Redux's usefulness you need sufficiently complex examples. That said, the explanation is as easy as saying Redux enables your frontend to be a state machine.
    - ratww 7y ago
      I don't think that's the problem per se. Reducers are very useful and simple to understand, and are great even on smaller apps. It's possible to see that in things like useReducer. IMO the problem with Redux is that you "need" all the boilerplate around it. I say "need" in quotes because you can easily get around it and not lose much (if anything). And if you do, you start to reap the benefits even in very small apps.
  - shantly 7y ago
    Part of why I only find React+Redux tolerable with TypeScript. Too much bouncing around, too many files open, otherwise. And that's before you layer any other crap on top of that (Saga and such). TypeScript makes it feel as simple as it actually is.
    - acemarke 7y ago
      Note that Redux Starter Kit is built in TypeScript itself, and `createSlice` makes it easy to write all the logic for a given slice in a single file. Then, combine that with our new React-Redux hooks API, and it really gets easy to work with Redux in your components: https://redux-starter-kit.js.org/tutorials/advanced-tutorial https://redux-starter-kit.js.org/tutorials/advanced-tutorial
- yawaramin 7y ago
  > Even the example in redux's own docs is unnecessarily complex. Well here's the issue, because if the project docs are unnecessarily complex then what hope does anyone have of learning the correct way? Come to HN and read your comment? No–the official documentation needs to speak for itself and be judged on its own merits. If you feel so strongly about how Redux should be taught, you can always send them a PR rearranging the docs and stay on them until it gets merged :-)
  - dragonwriter 7y ago
    > Well here's the issue, because if the project docs are unnecessarily complex then what hope does anyone have of learning the correct way? The same way one learns about anything the correct way; the Tao that can be told is not the true Tao. > No–the official documentation needs to speak for itself and be judged on its own merits. Sure the documentation needs to stand on its own merits, as does he code itself. That's different than judging the code by the (de)merits of the documentation though. “Redux is too complex” and “Redux has less-than-ideal documentation from an introductory perspective” are both potential problems, but they are distinct problems.
    - acemarke 7y ago
      I will gladly take any suggestions on how we can improve the docs in general, and the tutorials specifically :)
      - dragonwriter 7y ago
        Just to be clear, I wasn't saying Redux has such a problem with it's docs, just that GPs suggestion that it did was different than identifying a problem with the complexity of the software.
  - acemarke 7y ago
    We're already planning to revamp the docs in the _very_ near future (like, hopefully starting in the next couple weeks once I get Redux Starter Kit 1.0 out the door). See my proposed changes here: https://github.com/reduxjs/redux/issues/3313#issuecomment-450601554 https://github.com/reduxjs/redux/issues/3313#issuecomment-45...
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 ago
  Yes, 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...

nine_k 7y ago

I personally think that redux is very simple when you just explain its key idea. It only becomes complex when people trying to show a "cultured" way to write a large redux/react app bring in a ton of containers, controllers, action classes with methods for various auxiliary conveniences, etc. Even the example in redux's own docs is unnecessarily complex. This is not how you explain things. For an explanation, i'd use a single file, with 2-3 actions, using strings (or an enum) to denote actions, with a reducer right next to renderer, and a single-function react component. Then the data flow becomes apparent, and the usefulness of redux for keeping state within the unidirectional loop becomes also apparent. After getting the key idea, the reader will have an easy time understanding tools built around it, ways to fold up the boilerplate, etc. A react/redux app can be very compact and approachable, even when the logic is complex.

acemarke 7y ago
Yep, this is something I plan to do in our upcoming docs revamp. The initial tutorials will drop action creators, drop `const ADD_TODO = "ADD_TODO"`, drop splitting things into multiple files, etc. And yeah... a lot of the stuff normally associated with Redux is _intended_ as a "large project maintainability best practice" kind of thing.
- gimboland 7y ago
  Mark, your writings have really helped me to understand the redux landscape (inasmuch as I do), so I'd be curious to know what you think of this, if you've seen it: https://www.youtube.com/watch?v=JmnsEvoy-gY https://www.youtube.com/watch?v=JmnsEvoy-gY ("Good Action Hygiene with NgRx", Mike Ryan, NGConf April 2018) The context is ngrx but the territory is familiar. Two things struck me in particular: one (the key point of the talk) is the idea that actions should be named as effects not intentions. The other (which I loved) is the idea of having action types that look like (say) "[Todo List Page] Add Todo Clicked" rather than "ADD_TODO" — it certainly makes the history more legible in redux-devtools. (I'm unsure how to name my consts then, though; I'm going with TODO_LIST_PAGE_ADD_TODO_CLICKED but it's very verbose; in the video it looks like he's not bothering with consts at all, and is just using the strings directly at dispatch and reduce time, and maybe there's something in that — the strings are specific enough that there'd be no scope for confusion, I guess.) Just wondered what you thought of all this? I've read your idiomatic redux series, but maybe your thoughts have moved on since then...
  - acemarke 7y ago
    I have that talk bookmarked to watch, but my bookmarks queue is like 600+ deep at this point :) Just going by your summary: Yeah, I do find it interesting how some different parts of the community have chosen to format their action strings differently. Redux itself literally doesn't care, of course - the only requirement is that `action.type` not be undefined. As I said in "The Tao of Redux, Part 1: Implementation and Intent" [0], one of the main intents behind Redux is that the action log should be a literally readable history of what's going on in your app with semantic meaning behind each name. You _could_ have a single `"SET_DATA"` action, but that doesn't tell me anything about what's going on. The Redux docs originally went with the SCREAMING_SNAKE_CASE string format just because that's the common programming world convention for constant values. The naming in the docs also tends towards matching how you would name the action creator, ie, `"TOGGLE_TODO"` -> `toggleTodo()`. Those are perfectly legitimate choices to make, but definitely not the only possible ways to do it. I've seen plenty of other variations over the years, usually in the form of some "domain" string + the "event" name. For Redux Starter Kit, we've gone with a '/'-separated string, such as `"todos/addTodo"`. The end user is still supplying both parts (via the slice `name` field and the user-defined reducer function name). So, the Angular-ish convention of `"[Some Domain] Some Event"` is perfectly fine, and very readable. Either way, it doesn't matter what you actually name the _variable_ that points to that action type. One of the most interesting variations I've seen on this is Slack, which apparently uses entire _sentences_ as their action types, each including a unique numeric ID [1]. Finally, yes, we would generally recommend treating actions semantically as "events in the app", not "setters at a distance". Again, the Redux store itself doesn't care, but the "events" mental modeling promotes dispatching fewer total actions and having multiple reducers independently responding to a given action [2]. We'll emphasize this more in the upcoming docs revamp. Glad to know my writing has helped! Lemme know if you've got any other questions. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://twitter.com/erikras/status/1153350835738468363 https://twitter.com/erikras/status/1153350835738468363 [2] 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...
    - 7y ago
untog 7y ago
For me the problem with Redux is not that it’s complicated, it’s that it’s wildly verbose and adds a huge layer of misdirection to an app. Some apps are complex enough that they need this. In my experience, a lot of Redux apps really aren’t all that complicated, and people have used Redux because it’s The Thing To Do.
- oijoihodsf 7y ago
  I think that's the problem with demonstrating Redux, no? You start reaping the benefits when you need a state machine to manage complexity of your application. Thus, to demonstrate Redux's usefulness you need sufficiently complex examples. That said, the explanation is as easy as saying Redux enables your frontend to be a state machine.
  - ratww 7y ago
    I don't think that's the problem per se. Reducers are very useful and simple to understand, and are great even on smaller apps. It's possible to see that in things like useReducer. IMO the problem with Redux is that you "need" all the boilerplate around it. I say "need" in quotes because you can easily get around it and not lose much (if anything). And if you do, you start to reap the benefits even in very small apps.
- shantly 7y ago
  Part of why I only find React+Redux tolerable with TypeScript. Too much bouncing around, too many files open, otherwise. And that's before you layer any other crap on top of that (Saga and such). TypeScript makes it feel as simple as it actually is.
  - acemarke 7y ago
    Note that Redux Starter Kit is built in TypeScript itself, and `createSlice` makes it easy to write all the logic for a given slice in a single file. Then, combine that with our new React-Redux hooks API, and it really gets easy to work with Redux in your components: https://redux-starter-kit.js.org/tutorials/advanced-tutorial https://redux-starter-kit.js.org/tutorials/advanced-tutorial
yawaramin 7y ago
> Even the example in redux's own docs is unnecessarily complex. Well here's the issue, because if the project docs are unnecessarily complex then what hope does anyone have of learning the correct way? Come to HN and read your comment? No–the official documentation needs to speak for itself and be judged on its own merits. If you feel so strongly about how Redux should be taught, you can always send them a PR rearranging the docs and stay on them until it gets merged :-)
- dragonwriter 7y ago
  > Well here's the issue, because if the project docs are unnecessarily complex then what hope does anyone have of learning the correct way? The same way one learns about anything the correct way; the Tao that can be told is not the true Tao. > No–the official documentation needs to speak for itself and be judged on its own merits. Sure the documentation needs to stand on its own merits, as does he code itself. That's different than judging the code by the (de)merits of the documentation though. “Redux is too complex” and “Redux has less-than-ideal documentation from an introductory perspective” are both potential problems, but they are distinct problems.
  - acemarke 7y ago
    I will gladly take any suggestions on how we can improve the docs in general, and the tutorials specifically :)
    - dragonwriter 7y ago
      Just to be clear, I wasn't saying Redux has such a problem with it's docs, just that GPs suggestion that it did was different than identifying a problem with the complexity of the software.
- acemarke 7y ago
  We're already planning to revamp the docs in the _very_ near future (like, hopefully starting in the next couple weeks once I get Redux Starter Kit 1.0 out the door). See my proposed changes here: https://github.com/reduxjs/redux/issues/3313#issuecomment-450601554 https://github.com/reduxjs/redux/issues/3313#issuecomment-45...

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 ago
Yes, 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...