Breaking API changes for 1.0

[gaearon]

Naming

• “Stateless Stores” are now called reducers. (Proposal: Rename "stores" to "reducers" #137 (comment))
• The “Redux instance” is now called “The Store”. (Proposal: Rename "stores" to "reducers" #137 (comment))
• The dispatcher is removed completely. (Remove dispatcher (WIP) #166 (comment))

API changes

• composeStores is now composeReducers.
• createDispatcher is gone.
• createRedux is now createStore.
• <Provider> now accepts store prop instead of redux.
• The new createStore signature is createStore(reducer: Function | Object, initialState: any, middlewares: Array | ({ getState, dispatch }) => Array).
• If the first argument to createStore is an object, composeReducers is automatically applied to it.
• The “smart” middleware signature changed. It now accepts an object instead of a single getState function. The dispatch function lets you “recurse” the middleware chain and is useful for async: Time travel #113 (comment).

Correctness changes

• The dispatch provided by the default thunk middleware now walks the whole middleware chain.
• It is enforced now that raw Actions at the end of the middleware chain have to be plain objects.
• Nested dispatches are now handled gracefully. (Gracefully handle nested dispatches #110, Stateless dispatcher #119)

Internal changes

• The object in React context is renamed from redux to store.
• Some tests are rewritten for clarity, focus and edge cases.
• Redux in examples is now aliased to the source code for easier work on master.

[gaearon]

This PR supersedes #166, #119, and #120, and brings us much closer to 1.0 (#164).

The missing pieces for 1.0 are more strict composeReducers (#193), new docs (#140), and a more convenient action creator binding API (#86), if we are certain that we need it.

[gaearon]

Released on NPM as 1.0.0-alpha.

[dariocravero]

🎉 :)

[gaearon]

Whoops, this slipped in by mistake when copy-pasting.

[acdlite]

Yay! Looks good!

I've been wondering if composeReducers() is really the best name for that function. The name is very generic, whereas its implementation is very specific.

Consider another common way of composing reducers, which is to apply each one of them in sequence:

(...reducers) => (prevState, action) =>
  reducers.reduce(
    (state, r) => r(state, action),
    prevState
  );

This could also be named composeReducers(). (I'd actually argue this is better fit for the name.)

Maybe we should think of a more specific name? Don't have any suggestions right now, but I wonder what everyone else's thoughts are.

[gaearon]

@acdlite Any precedents in other libraries' APIs?

[dbrans]

Where does the name "thunk" come from?

[iamdustan]

as in so? https://en.wikipedia.org/wiki/Thunk

[clearjs]

https://github.com/tj/co#thunks

[emmenko]

@gaearon one step forward, great work! 👍

[iamdustan]

I’m curious why a second ::store.getState function is created instead of reusing the one from #L20?

[gaearon]

Overlooked this :-). No real reason

[rpominov]

I've been wondering if composeReducers() is really the best name for that function.
Maybe we should think of a more specific name? Don't have any suggestions right now, but I wonder what everyone else's thoughts are.

combineReducers() maybe?

[gaearon]

I like combine.

[ghost]

2.5 (insanely hectic for you)months from "Initial Commit" to "1.0" is kind of crazy... Nice work :)