Update middleware api

[acdlite]

This PR updates the middleware API in several ways.

All middleware is now smart middleware

The API becomes much simpler if we just assume that all middleware is "smart" middleware. I know previously I argued against something like this:

(dispatch, getState, next) => action => {...}

because it's fragile, hard to compose, and awkward to use from the call site. I also figured most middleware wouldn't need either dispatch() or getState(). But as we discovered with the thunk middleware, any asynchronous middleware is going to need dispatch() so that it can dispatch from the beginning of the chain. So let's just make all middleware "smart" like this:

methods => next => action {...}

where methods is a subset of the store, currently { dispatch, getState }. Now it's easy to compose using just function composition. And if users have already written their own "dumb" middleware, all they need to do to update is wrap it in one more function:

const smartMiddleware = () => dumbMiddleware;

applyMiddleware(...middlewares)

Now that all middleware is smart middleware, we don't have to deal with this nonsense. We get a nice, simple API for applying middleware:

const finalCreateStore = applyMiddleware(thunk, promise, observable)(createStore);

applyMiddleware() is a higher-order store, just like @gaearon's devtools (I assume... haven't seen the final version yet.). So, it composes!

const finalCreateStore = compose(
  applyMiddleware(thunk, promise, observable)
  devtools,
  createStore
);

Caveat: thunkMiddleware() is no longer built-in to createStore()

This is because middleware needs to come before any other higher-order stores, since middleware has the potential to be asynchronous.

However! It is still the default when using applyMiddleware(). It's additional step versus today, but I imagine most users will be using applyMiddleware, anyway:

const finalCreateStore = applyMiddleware()(createStore);

// Same as
const finalCreateStore = applyMiddleware(thunk)(createStore);

Updated composeMiddleware()

I updated composeMiddleware() to support the new signature. In the process, I also discovered a bug with the previous implementation where it only works if dispatch is the last argument. It did not combine multiple middlewares into a single middlewares as advertised; it only combined multiple middlewares with dispatch to create a new dispatch.

The reason is because it was simply doing function composition, where compose(a, b, c) becomes a(b(c)). But this isn't right, because this

m1(m2(m3(dispatch))

is not the same this

m1(m2(m3))(dispatch)

Which means previously we couldn't do this, as advertised in the docs (and by, ya know, the name of the function):

const middleware = composeMiddleware(m1, m2, m3);
const finalDispatch = middleware(dispatch);

I fixed the issue and updated the test. We'll need to update the docs in master, too, as they're currently incorrect.

I've renamed the previous method to just compose(), since it's still useful elsewhere.

[gaearon]

Thanks for tackling this. I was shuffling this around in my head today but didn't settle on anything.

I'll take a close look on Monday or Tuesday. Pretty sure this is going in.

[aaronjensen]

Should we consider having the default thunk middleware send the same methods type object to action instead of splitting them into separate parameters like this? i.e.

action({ dispatch, getState })

[acdlite]

I thought about that, too, but 9 times out of 10 a thunk just needs dispatch(), and single argument form is easier.

[gaearon]

I understand it now. Great job.