Redux: Proposal: Rename "stores" to "reducers"

-1 the learning curve on this repo already feels steep. Let's not make it any steeper by introducing new terminology for new flux users.

Internally they can be called reducers, publicly keep them as stores so it's easier to grok.

I honestly think it's more confusing the way it is now. Totally anecdotal, but I've had several people IRL get all messed up thinking about how a "store" could be stateless.

The main characteristics of "stores" in traditional Flux are that they 1) hold state, and 2) emit change events. Neither of which are true in Redux.

I agree we need to clarify the terminology, and in some cases find better naming.
I think as a first step there should be some JSDoc, then a terminology section would also help.
In general we have to maintain a certain level of consistency.

I wonder if there's a term that doesn't sound FP-ish but is not a “store” either.
Domains?

OTOH it's already called Redux so at least “reducer” sounds related.

How about "step updates", or "steppers", which moves your state one step forward. I've seen this being used in Elm literature, having a function called step, update, or next

Domains contain node.js baggage.

They're not stores in how they function but you still put your state logic in there much like flux stores. They're state managers, like flux stores are supposed to be.

Reducers is fine if you're keen on changing its name though.

Especially because "reducer" is a precise description of what they actually are :)

Updaters? Sounds descriptive + less snobbish than reducers.

I like reducer as well

I guess I don't see why "reducer" is snobbish. Isn't it better to use the actual term than invent a new one that is less descriptive?

I guess both may be valid, and it depends from which point of view you see it: a _reducer_ of actions (into state), or an _updater_ of state.

"Updater" implies that its mutative. "Reducer" makes it clear that you're returning a new state, not modifying the old one.

That's a strong point in favor I think, may help with the issue about redux not working correctly with mutations

I do appreciate the need to keep Redux friendly to people who aren't familiar with FP, but we can solve that with better documentation. I like the current docs, but on first glance they're a bit overwhelming. A good docs site that foregrounds the familiar stuff (action creators, reducer logic) over the advanced stuff (middleware, hot reloading) would be very helpful.

And yet, judging from the rapid growth of the following here, we must be doing something right :)

I'm open to changing “Stores” to “Reducers” if this happens together with better docs.

The essential element is to preserve the “it's like Flux but better, don't worry” vibe. I don't want people to think it's similar to Reflux or something, which sounds like Flux but breaks some of its nice properties. I also don't want them to think they need to learn FP. As long as we can keep it so, I'm okay with this change.

Suggestion I'm less sure about: If we rename the Redux class to Store (think about it: its two purposes are to hold state and emit change events) then the top-level API becomes:

const store = createStore(reducers);

<Provider store={store} />

This communicates the idea pretty well, I think. Reducers are where your store logic goes, but they are not stores themselves.

I like this although store.dispatch feels wrong then.

Yeah that's the one thing I don't really like, but the other methods makes sense: store.getState(), store.setState(), store.subscribe()

Now that I think of it, we're not really “dispatching” anything.
Ugh, naming is a rabbit hole.

Ok, so what we have so far are:

• action (creators)
• (store) reducer
• middleware functions
• callback (listener) functions
• something that triggers the functions call chain (called dispatcher)
• something that holds the mutable state (with setters and getters)

Maybe we can take a step back and re-think the naming?

Maybe store.dispatch is not too bad. We can just explain that instead of many Stores, we have a single Store, and you compose it from Reducers. No Stores = no need for a separate Dispatcher, so dispatch is available right on Store.

@gaearon I agree.

@emmenko Good summary. Any terminology breakdown should distinguish between _action creators_ and _actions_. It should also distinguish between the _dispatcher_ or _dispatch strategy_, which encompasses middleware + reducers, as well as the _dispatch_ method which triggers a _dispatch cycle_.

Let's do this:

• Rename Stores to Reducers
• Rename the “Redux instance” to Store as per https://github.com/gaearon/redux/issues/137#issuecomment-113252359
• Explain that if you squint at traditional Flux Stores, you'll see Reducers trapped in them

Anybody want to lead the new docs effort? It'll need some structuring: a glossary, a README, a simple “get-it-running” tutorial, and maybe an more in-depth “design decisions” guide.

@gaearon I'll volunteer to lead this :) I have an outline started already.

Thanks :+1:

I'll volunteer to lead this

Thanks! :+1: :+1: :+1:

Personally, as a final outcome, I would really like to have an auto-generated website with:

• getting started
• tutorials
• live examples

...and as a nice-to-have feature:

• generated documentation a-la docco (e.g.: like jasmine) so that the source code is clearly explained

But starting with markdown and jsdoc is of course a first step ;)

Right, I think the first step is getting the docs written in Markdown form, then we can port them to a really nice docs site. :+1: for JSDoc, too. I'm going to take one final stab at https://github.com/gaearon/redux/pull/87 tonight but I'm not sure Flow annotations are worth it at this point unless we rid the codebase of function overloading. (Or unless someone teaches me how to properly type them without Flow complaining.)

I guess Flow is not a priority atm.

+1 for stores being called reducers.

I've not been fond of calling these more declarative, stateless things stores.

I like the new name ideas. I'd also propose renaming Connector to something like Subscription. Connector is very generic, and while I get that it is connecting redux's state and dispatcher to its children, I think that a subscription is a better description of what is happening. It's a bit of a stretch that you get a dispatcher along w/ your subscription, but I think that's ok.

-1 for stores being called reducers, as a name it's not very intuitive for new users (at least those without a functional programming background). Maybe Updater or Transformer would be better, or Store Updater if we wanted to be more explicit about it.

“Transformers” have been suggested quite a few times. It doesn't suggest mutable nature like Updaters, is more approachable than Reducers, and doesn't carry the “storage” connotation of Stores.

How do you like Transformers?

+1 for Reducers

As noted by @faassen on Twitter, a good argument for “reducers” is calling back to the project name. We have a chance to say “This is like Flux, but there is a single Store. Just like you can compose your app into React components, in Redux, you compose that Store out of Reducers. They are called Reducers because their signature matches function passed to [].reduce(): (state, action) => state. Bla bla bla”

angular spread like wildfire and uses words like

• directive
• isolate
• transclude

Ignoring programming, transforming and reducing are different things. I'd pick the name that is the most accurate.

If they don't store data, don't call them stores.

Are you transforming from one form to another or are you reducing from many values to one?

Transformer => map
Reducer => reduce

Sounds like reduce to me.

I'm for reducers too! :+1:

Take inspiration from Elm. https://github.com/evancz/elm-architecture-tutorial#the-basic-pattern

The best word would be update. Store is nonsense, it has always been "Model". No need to reinvent the wheel or confuse people.

My beef with calling them updaters is people might think they are supposed to be mutative. If the naming can help clarify non-mutative nature that would be a huge bonus.

Are you transforming from one form to another or are you reducing from many values to one?

I'm accumulating. “How an action turns a state into the next state.” Conceptually they're reducing over many actions from the initial (undefined) state, and memoization is just an optimization.

State Transformer

Try to avoid reinventing/rediscovering as much as possible. People have been calling it reduce, scan, fold, and update.

reducer seems to be accurate from a javascript perspective...
Don't see the value to name it from a concept of another language, even if it's more accurate.

Don't have a firm stand on what it should be but IMO it should be something that most accurately represents the type of computation. If it's an umfaliar word to most programmers then that can be offset by documentation.

@vramana it is not a map, it is a reduce, since it takes the previously accumulated state and a new action and returns a new state.

If you had an array of all the actions of your app, you'd use this function to reduce it to the final app state:

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

Now, what you really have is a stream of actions in time, which is conceptually the same as an array, but in time (you can reduce it into a stream of states).

I like to think of it as a projection (of an event log to a data structure).
DB people used to call this "materialized views".

I like reduce or fold, it is well understood by different communities

I much prefer Transformers to Reducers: it's clear what it means from the normal English usage of the word.

Reducers.
First, it's javascript library and javascript has [].reduce(reducer, initialState).
Second, Redu(cer)x is already in library name.
Third, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , other people and libraries will use 'reducers' term.

Reducer is accurate and has a precedent in vanilla JS. Not sure how that could be improved on.

Reducers it shall be then.

(Follow progress in #140)

Occasionally I find old discussions calling them “stores” and marvel at how ridiculously confusing it was in the hindsight.

"state container"?

Yes this was a good change :)