To be fair, you don't really need to declare your constants elsewhere. This is just a pattern people stuck with, because they're stubborn about constants, I think. Doing a find/replace is so incredibly easy that it's kind of silly to add a bunch more boilerplate to protect against one DRY quip.

I'm a really big fan of the Ducks pattern where your action types are private to each reducer unless they're explicitly exported as an API. In my own code I don't even do that, instead exporting a function which operates on the state.

https://github.com/erikras/ducks-modular-redux

Hm, interesting. I like it. I'm also curious about how selectors come into play here as well (exported getter functions for shielding app from reducer state shape).

You might still need to place actions/selectors in their own directory since they're not necessarily specific to any reducer. I believe this is how sagas are organized, though.

I refuse to believe VueX is any simpler than Redux: https://github.com/vuejs/vuex/blob/dev/examples/counter/stor...

Also you don't have to import your actions, it's just a smart thing to do. This gives me heartache a bit: https://github.com/vuejs/vuex/blob/dev/examples/counter/Coun...

Vuex is simpler than Redux. First you don't have to grasp the Container/Component pattern. Second you have less middleware ("what, you don't use redux-saga and redux-think?").

Vue and Vuex seem less clever JS (shiny es6 features), less clever programming (mutability etc) which I feel may be a detriment for complex apps in the long term but it is simpler.

(I may be biased because before Vue and React/Redux I did Angular1 & React/Reflux and I view Vue as a Angular/React mix and Vuex is not far from Reflux)

> Container/Component

That's not part of Redux, it's a separate design pattern you can use with any Flux architecture. React-Redux doesn't even require you to do it that way, and for good reason: you might not need it. There's nothing wrong with just importing a store reference wherever you want it. That's a totally reasonable pattern for some applications.

This illustrates my point I guess. There's so many people thinking about how to architect and implement React applications that there's a lot of cargo-culting.

That's not part of Redux, maybe, but it's very prominent in the official tutorial in the basic section : https://redux.js.org/docs/basics/UsageWithReact.html

It's not, it's literally the same (they said VueX is based on Redux). The difference is React.

I disagree that its "literally" the same. Vuex requires you to mutate state, through their API (if declaring new/dynamic properties). Redux is agnostic about how you handle state, but encourages immutability. Vuex is inherently not immutable, its coupled to the vue reactivity system which is based on mutations & memoization.

Vuex & Vue are the easier APIs to learn. Not only that the developer ergonomics are just better for Vue's API. For example in vue you have "mounted()" instead of "componentDidMount()" or "ngOnInit()". Likewise, redux requires learning CS terms (if you don't know them) like thunk, saga, memoized selectors, etc. Vue uses more layman's terms, like "computed" instead of "memoized selector" which just makes it easier to learn.

My big hangup with Vue is having to declare reactive properties up front. It's author says this is a best practice anyways, but it leads to hard to debug issues when you accidentally declare new properties at runtime & you get race conditions. With react & redux both making immutability possible & encouraging immutability, you get easier to debug apps. But there is a more up front investment.

I also really love Vue's single file components. I know you can do that in Angular & React, but again the API is just so much more ergonomic in Vue.

It looks like VueX supports async out of the box. That's a huge win IMO.

Is it? I thought Redux abstracting out the thunk layer was silly until that line of thinking lead to Redux-Saga. It actually seems to have been a pretty smart move.

There's vuex-saga as well. Something built in would have been nice because even though sagas are cool, the learning curve is steep enough for me to avoid it in projects.