[mychael]

A big contributor to the difficult learning curve in Redux is the very poor naming of things. It's off the charts unintuitive, especially if you're an experienced programmer.

I imagine their thought process went like this:

Types: People like strongly typed languages, maybe if we call our events "types", they will like Redux more?

Reducers: Switch statements are so boring and uncool. Lets call this "reducer" instead of "events switch statement".

Store: Lets call the state tree "store". The term "State tree" is too explicit and a core principle of Redux is misdirection.

Actions: Mere mortals will associate the term "action" with functions and procedures, but Redux is not for mortals. "Action" will be our term for payload.

[gpmcadam]

Given that Redux is an implementation of the Flux pattern, your grievances may actually be with the naming conventions in Flux itself.

https://facebook.github.io/flux/docs/in-depth-overview.html#...

[mychael]

Your Flux/Redux point is a distinction without a difference. The names are bad, wherever they came from.

[acemarke]

This is the thing that everyone seems to have forgotten. Redux didn't invent these terms out of nothing. Redux was specifically written as an implementation of the Flux Architecture, and the terms "store", "action", and "type" came directly from Flux. The term "reducer" had been in use with Clojure already, I think, and is based on the way these functions have the same signature as a callback you pass to `Array.prototype.reduce`. "State" is a generic term meaning "data in your app", and the term "tree" for a hierarchy of objects has been around for ever. (Oh, and you can write your reducer functions with _whatever conditional logic you want_ - switch statements just happen to be an obvious way to handle multiple values for a single field.)

I covered a lot of the history and thought behind Redux's design in my post "The Tao of Redux, Part 1: Implementation and Intent" [0] .

Sure, I'd agree that the terms are a lot to take in for a new learner, but claiming these were chosen or made up to make things more confusing is ridiculous. There was a lot of debate over exactly what terms to use during the development process [1] [2] [3], and it was ultimately decided that keeping the Flux-based terminology made the most sense at the time, because most people coming to Redux were familiar with Flux already. Obviously the dev landscape has changed since then, since nobody seems to remember that the original Flux concept existed, but the terms are now set in stone because we've been using them since the beginning.

[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[1] "reducers": https://github.com/reduxjs/redux/issues/137

[2] "state", "store", "dispatch" : https://github.com/reduxjs/redux/issues/113 , https://github.com/reduxjs/redux/issues/137

[3] "actions" vs "events": https://github.com/reduxjs/redux/issues/384 , https://github.com/reduxjs/redux/issues/377 , https://github.com/reduxjs/redux/issues/891

[acemarke]

One other addendum:

The "store" is the object returned from `createStore()`, which has the `dispatch`, `getState`, and `subscribe` methods.

The store object contains your "state" value, which could be a simple number by itself, an array, an object, or whatever else you return.

Typically that top level value _is_ an object with other values nested inside of it, and _that_ is your "state tree". So, the "store" contains the "state tree", and they are not the same thing.