4 ms·

That's exactly how I do it. Vuex makes this super simple due to the fact that if you need the authoritative data in any component in the tree you can grab it fr

That's exactly how I do it. Vuex makes this super simple due to the fact that if you need the authoritative data in any component in the tree you can grab it from the central store by using getters at negligible overhead. Vue really got it right using the prototype extension model for plugins. I use React+Redux at my day job and I have to say that it is an absolute pain in the ass to do state management with Redux vs Vuex. Redux forces you to split all of your logic out into separate tiny little functions and constants. It even encourages you to split this all out into separate files. Between the api functions, actions, reducers, connectors, routers, it all gets very complex very quickly. The worst part is using `react-redux` and creating connectors where I have to explicitly pass whatever actions and state I want to use explicitly to a container where I need to propagate that state to a component that's nested five levels deep. Then, if that component needs to dispatch an action I have to propagate the event through 5 different callbacks to get it back to the connected container. With Vuex, I can access the store in any component in one line and dispatch actions to the store from any component anywhere in the tree and rest easy knowing my component tree will update with the data changes. I'm seriously considering starting a re-write in Vue at this point because It's much easier to maintain and refactor.

ng12 9y ago
You can do that in Redux. Just put your store somewhere you can import it or write a little utility so each component is connected to the entire state. The reason people don't is to keep them honest about abstraction layers, separation of concerns, and reusability.
- scriptkiddy 9y ago
  I've thought about doing that. However, it doesn't really seem to play well with React's architecture. For instance, React does not have any built in support for computed properties. Therefore, if I am returning data from the central store through a function on a component that calls a getter from the store, the component will not update if the central state changes during the component's life cycle. Of course I could write a polling function or some sort of watcher method that binds the computed properties to component state, but that sounds like a mess. At a certain point after trying to get React to act more like like Vue, I have to ask myself why I'm not just using Vue in the first place. Regarding you statement about abstraction layers, separation of concerns, and re-usability: If I want a generic and re-usable component I just won't give it any data state. It may have local presentation state, but all data will be passed to it from a parent. Any operations the component allows will simply emit events. Both Vue and React are equally suitable for this and I have no complaints about either for generic components. I'm not sure how being able to read central state in any component violates separation of concerns, however. The store is still handing all mutations to application state in Redux or Vuex. The difference with Vuex is that You do not need to have a chain of callbacks for dispatching actions, you do not need "connected containers", and you do not need to pass state through components in a tree that do not require that state. For instance, say I have a user profile page. This page displays user information received from a REST detail endpoint. Simple enough, right? I just have a `UserProfileContainer` where I define functions for fetching the user object from the API and then getters for retrieving that state. Now, I decide that I want to display a user's recent activities in a feed on the same page. Do I add to my `UserProfileContainer` to pass state down to the new feed component and it's children, or do I define the feed component as a new container? Or, do I define an intermediary `UserProfileLayout` component that is not a container and handles delegating state passed to it from the `UserProfileContainer`? If I do that I am passing application state through a component that has no use for it and I have to define an addional callback to propagate the event back to `UserProfileContainer`. Or maybe I should use `UserProfileContainer` itself to delegate state to the `UserInfo` and `UserFeed` components? How you compose this theoretical interface is probably defined by the structure of the rest of the application. I'm simply stating the Redux becomes more and more difficult to work with as the depth of component nesting increases.
  - ng12 9y ago
    I'm not sure what your complaint is about computed properties. You should either store the computed data in the reducer, compute it on the fly in render, or use componentWillReceiveProps and/or setState. Your problem isn't needing to make React behave like Vue, you need to let React behave like React. The second point I was trying to make is you don't have to do it that way in React. React is a perfectly functional framework without Redux or the "container" model. That style became popular because you're enforcing that the majority of your components are dumb [1] which is a pretty useful thing for a large project. But again, these aren't problems with React and if it's giving you this much heartburn it's worth bringing up with your team because it sounds like something's going wrong. 1. https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
    - scriptkiddy 9y ago
      Thank you for the link, but I've already read that article. I realize that the way my team is doing things is not the only way. It's difficult to change the minds of people who are already set in their ways even when you're in charge. My team believes that the method which I described above is the "best practice" way of composing with react. I disagree, but I need to work with what my team is comfortable with.
  - deleted 9y ago
    [deleted]
acemarke 9y ago
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 9y 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)?

ng12 9y ago

You can do that in Redux. Just put your store somewhere you can import it or write a little utility so each component is connected to the entire state. The reason people don't is to keep them honest about abstraction layers, separation of concerns, and reusability.

scriptkiddy 9y ago
I've thought about doing that. However, it doesn't really seem to play well with React's architecture. For instance, React does not have any built in support for computed properties. Therefore, if I am returning data from the central store through a function on a component that calls a getter from the store, the component will not update if the central state changes during the component's life cycle. Of course I could write a polling function or some sort of watcher method that binds the computed properties to component state, but that sounds like a mess. At a certain point after trying to get React to act more like like Vue, I have to ask myself why I'm not just using Vue in the first place. Regarding you statement about abstraction layers, separation of concerns, and re-usability: If I want a generic and re-usable component I just won't give it any data state. It may have local presentation state, but all data will be passed to it from a parent. Any operations the component allows will simply emit events. Both Vue and React are equally suitable for this and I have no complaints about either for generic components. I'm not sure how being able to read central state in any component violates separation of concerns, however. The store is still handing all mutations to application state in Redux or Vuex. The difference with Vuex is that You do not need to have a chain of callbacks for dispatching actions, you do not need "connected containers", and you do not need to pass state through components in a tree that do not require that state. For instance, say I have a user profile page. This page displays user information received from a REST detail endpoint. Simple enough, right? I just have a `UserProfileContainer` where I define functions for fetching the user object from the API and then getters for retrieving that state. Now, I decide that I want to display a user's recent activities in a feed on the same page. Do I add to my `UserProfileContainer` to pass state down to the new feed component and it's children, or do I define the feed component as a new container? Or, do I define an intermediary `UserProfileLayout` component that is not a container and handles delegating state passed to it from the `UserProfileContainer`? If I do that I am passing application state through a component that has no use for it and I have to define an addional callback to propagate the event back to `UserProfileContainer`. Or maybe I should use `UserProfileContainer` itself to delegate state to the `UserInfo` and `UserFeed` components? How you compose this theoretical interface is probably defined by the structure of the rest of the application. I'm simply stating the Redux becomes more and more difficult to work with as the depth of component nesting increases.
- ng12 9y ago
  I'm not sure what your complaint is about computed properties. You should either store the computed data in the reducer, compute it on the fly in render, or use componentWillReceiveProps and/or setState. Your problem isn't needing to make React behave like Vue, you need to let React behave like React. The second point I was trying to make is you don't have to do it that way in React. React is a perfectly functional framework without Redux or the "container" model. That style became popular because you're enforcing that the majority of your components are dumb [1] which is a pretty useful thing for a large project. But again, these aren't problems with React and if it's giving you this much heartburn it's worth bringing up with your team because it sounds like something's going wrong. 1. https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
  - scriptkiddy 9y ago
    Thank you for the link, but I've already read that article. I realize that the way my team is doing things is not the only way. It's difficult to change the minds of people who are already set in their ways even when you're in charge. My team believes that the method which I described above is the "best practice" way of composing with react. I disagree, but I need to work with what my team is comfortable with.
- deleted 9y ago
  [deleted]

acemarke 9y ago

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 9y 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)?