4 ms·

Hi. I'm a Redux maintainer. A few quick thoughts. First, Redux does not _force_ you to split your logic up into "separate tiny little functions". That's the

Hi. I'm a Redux maintainer. A few quick thoughts. First, Redux does not _force_ you to split your logic up into "separate tiny little functions". That's the _encouraged_ approach, but you are absolutely free to structure your reducer logic any way you want. You may want to read through the "Structuring Reducers" section I wrote for the docs: http://redux.js.org/docs/recipes/StructuringReducers.html http://redux.js.org/docs/recipes/StructuringReducers.html . Second, you _can_ manually write logic in each of your components to access the Redux store via React context. However, the point of the React-Redux `connect` function is to generate "container" components that manage that store interaction logic for you, allowing you to focus on writing more "presentational" components that simply receive functions and values as props. You _can_ even directly import the store into your component files and reference it directly, although that's discouraged for several reasons (per the Redux FAQ at http://redux.js.org/docs/faq/StoreSetup.html#store-setup-multiple-stores http://redux.js.org/docs/faq/StoreSetup.html#store-setup-mul... ). Third, you shouldn't need to "propagate an event through 5 different callbacks". One of the main points of Redux is that you can `connect()` _any_ component to give it access to the store. If a deeply nested component needs to extract a couple values from the store, or dispatch an action, go ahead and connect it - you don't have limit yourself to only a couple connected components higher up in the tree (per http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-components http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-... ). Lemme toss out a few resources for you. I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. Also, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com https://www.reactiflux.com . Please feel free to drop by and discuss any pain points or questions you have. I'm usually online evenings US time, and there's always a bunch of people happy to discuss things.

IgorPartola 10y ago
Since you are here, would you mind doing a quick comparison between Redux and Vuex? I settled on Vue/Vuex over React/Redux specifically because Redux seemed to have more complexity when it came to mutations, promises, etc. Why did Redux choose the path it did and what is the advantage of using it over Vuex (of course other than the rendering libraries they work with respectively)?
- acemarke 10y ago
  To be honest, I really haven't read up on Vue or Vuex at all, so I can't make any good comparisons. I _can_ say that I'm currently working on a blog post that will discuss what actual technical limitations Redux requires (and where/why those limitations exist), vs how Redux is _intended_ to be used, vs how it's _possible_ to use Redux. I've been doing research for that post by reviewing many of the early Redux issues and discussions, and will be including some of that info in my post. Hoping to make progress on that post this weekend - if you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com http://blog.isquaredsoftware.com . I did write a comment on Reddit yesterday where I pasted a quote of Redux's stated objectives from an early version of the README, which may be informative: https://www.reddit.com/r/javascript/comments/67gvic/i_just_dont_get_what_is_worth_the_extra/dgqbhmb/ https://www.reddit.com/r/javascript/comments/67gvic/i_just_d... . In general, Dan and Andrew's primary goals were to enable time-travel debugging, server rendering, and state traceability, as well as offering up extension points so that developers could customize things like async behavior for their own preferences. That led to the effective requirements of immutable data handling, composed functions for organizing "write" logic, and the creation of "middleware" as the preferred approach for implementing async handling.
scriptkiddy 10y ago
First off, I just want to say that my criticisms are in no way meant to demean the quality of work of the Redux contributors. Redux is the best solution for single state management in the React ecosystem and it is a very well made library. Thanks for all of your effort. My criticisms are just me simply voicing my frustration with, what seems to me, to be the generally accepted "best practice" for composing Redux applications. Let me give you some short background: I've being doing backend work for years. Last year I signed on with a new project where I was in charge of both front and back-end work. Because of this, I was introduced to the modern front-end ecosystem and all of its intricacies. We've come a long way from jQuery. After evaluating many different front end libraries against project requirements it came down to using either Vue or React. We chose React because of its wider adoption. Eventually we hired on 2 front-end developers so I could focus on the server side of things. Well, here comes the project deadline and I'm having to pick up slack on the front-end. Now, since the new front-end devs re-wrote the entire front-end, I am struggling to understand why they structured it the way they did. They insist that having huge containers passing state down through multiple dumb components is the best way to structure the application. I feel like it introduces unnecessary complexity. Because our front-end devs have more experience in front-end development(obviously), I need to trust their judgment. I hope that helps you understand my frustrations. >You _can_ even directly import the store into your component files and reference it directly, although that's discouraged for several reasons (per the Redux FAQ at http://redux.js.org/docs/faq/StoreSetup.html#store-setup-mul.. http://redux.js.org/docs/faq/StoreSetup.html#store-setup-mul.... ). Yes, I definitely want to steer clear of this pattern. >Third, you shouldn't need to "propagate an event through 5 different callbacks". One of the main points of Redux is that you can `connect()` _any_ component to give it access to the store. If a deeply nested component needs to extract a couple values from the store, or dispatch an action, go ahead and connect it - you don't have limit yourself to only a couple connected components higher up in the tree (per http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-.. http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-.... ). I should show this to my team. Maybe a Redux maintainer will do a better job convincing them than I will. >I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. Thank you for this.

IgorPartola 10y ago

Since you are here, would you mind doing a quick comparison between Redux and Vuex? I settled on Vue/Vuex over React/Redux specifically because Redux seemed to have more complexity when it came to mutations, promises, etc. Why did Redux choose the path it did and what is the advantage of using it over Vuex (of course other than the rendering libraries they work with respectively)?

acemarke 10y ago
To be honest, I really haven't read up on Vue or Vuex at all, so I can't make any good comparisons. I _can_ say that I'm currently working on a blog post that will discuss what actual technical limitations Redux requires (and where/why those limitations exist), vs how Redux is _intended_ to be used, vs how it's _possible_ to use Redux. I've been doing research for that post by reviewing many of the early Redux issues and discussions, and will be including some of that info in my post. Hoping to make progress on that post this weekend - if you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com http://blog.isquaredsoftware.com . I did write a comment on Reddit yesterday where I pasted a quote of Redux's stated objectives from an early version of the README, which may be informative: https://www.reddit.com/r/javascript/comments/67gvic/i_just_dont_get_what_is_worth_the_extra/dgqbhmb/ https://www.reddit.com/r/javascript/comments/67gvic/i_just_d... . In general, Dan and Andrew's primary goals were to enable time-travel debugging, server rendering, and state traceability, as well as offering up extension points so that developers could customize things like async behavior for their own preferences. That led to the effective requirements of immutable data handling, composed functions for organizing "write" logic, and the creation of "middleware" as the preferred approach for implementing async handling.

scriptkiddy 10y ago

First off, I just want to say that my criticisms are in no way meant to demean the quality of work of the Redux contributors. Redux is the best solution for single state management in the React ecosystem and it is a very well made library. Thanks for all of your effort. My criticisms are just me simply voicing my frustration with, what seems to me, to be the generally accepted "best practice" for composing Redux applications. Let me give you some short background: I've being doing backend work for years. Last year I signed on with a new project where I was in charge of both front and back-end work. Because of this, I was introduced to the modern front-end ecosystem and all of its intricacies. We've come a long way from jQuery. After evaluating many different front end libraries against project requirements it came down to using either Vue or React. We chose React because of its wider adoption. Eventually we hired on 2 front-end developers so I could focus on the server side of things. Well, here comes the project deadline and I'm having to pick up slack on the front-end. Now, since the new front-end devs re-wrote the entire front-end, I am struggling to understand why they structured it the way they did. They insist that having huge containers passing state down through multiple dumb components is the best way to structure the application. I feel like it introduces unnecessary complexity. Because our front-end devs have more experience in front-end development(obviously), I need to trust their judgment. I hope that helps you understand my frustrations. >You _can_ even directly import the store into your component files and reference it directly, although that's discouraged for several reasons (per the Redux FAQ at http://redux.js.org/docs/faq/StoreSetup.html#store-setup-mul.. http://redux.js.org/docs/faq/StoreSetup.html#store-setup-mul.... ). Yes, I definitely want to steer clear of this pattern. >Third, you shouldn't need to "propagate an event through 5 different callbacks". One of the main points of Redux is that you can `connect()` _any_ component to give it access to the store. If a deeply nested component needs to extract a couple values from the store, or dispatch an action, go ahead and connect it - you don't have limit yourself to only a couple connected components higher up in the tree (per http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-.. http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-.... ). I should show this to my team. Maybe a Redux maintainer will do a better job convincing them than I will. >I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. Thank you for this.