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 fo

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.