Export default middlewares and use consistent naming

[emmenko]

To be consistent with e.g.: composeStores.

Also exporting the default thunk middleware is useful if I need to create a dispatcher with other middlewares, for example:

import { createDispatcher, composeStores, middlewares } = 'redux';
import loggerMiddleware from './middlewares/logger';
import * as stores from './stores';

const dispatcher = createDispatcher(
  composeStores(stores),
  getState => [middlewares.thunk(getState), loggerMiddleware(getState)]
);

Does it make sense?

[gaearon]

I'd rather not export “middlewares” because it leaves the impression that Redux plans to include many different middlewares (when in fact the opposite is true: we only ship with thunk middleware).

I agree about compose => composeMiddlewares though. It's too generic right now. I understand it's just functional composition, but I think we still need to clarify the intent.

On a sidenote, would composeMiddleware be a better name English-wise?

[acdlite]

👍 for renaming to composeMiddleware and leaving off the 's'.

[gaearon]

👍 for renaming to composeMiddleware and leaving off the 's'.

If we do that, let's change “middlewares” parameter name inside createDispatcher and composeMiddleware as well.

[acdlite]

If we do that, let's change “middlewares” parameter name inside createDispatcher and composeMiddleware as well.

I think the 's' is useful there to clarify that it's an array, not a single middleware.

[gaearon]

Good point. Let's do this then:

• Keep the parameter name middlewares
• Change the function to be composeMiddleware
• Keep thunk in ./middleware and don't export it

[emmenko]

Since there will be only one default middleware, how about just exporting it as defaultMiddleware?

The only reason for exporting it is to avoid doing import thunk from 'redux/lib/middleware/thunk. Imports should not rely on internal structure...

[acdlite]

I don't think redux/middleware/thunk would be so bad. The alternative is to publish it separately on npm, which... I dunno, feels like overkill for a 10 line function :D

[acdlite]

Also I don't like defaultMiddleware because it doesn't describe what it actually does.

[emmenko]

Right...I don't know, I'm just trying to make it easier to just re-use this middleware instead of copy-paste it.

How about instead having a addMiddleware in the dispatcher? So if I'm happy with the default dispatcher (with thunk middleware) I'll keep it and just add other middlewares. If I want something completely custom, then I just create my own middleware...

[gaearon]

How about instead having a addMiddleware in the dispatcher?

But then you'd need clearMiddleware to also delete the default one? What we have now sounds much simpler to me.

I'm just trying to make it easier to just re-use this middleware instead of copy-paste it.

I think it's easy enough to be honest. You either need thunk middleware (and in this case it's good to understand what thunk means anyway because you're going to try composing it with something else), or you don't need it.

[emmenko]

Ok, let's keep it like this for now. If there is actually a need we can re-discuss it.

Should I just do the renaming then?

[gaearon]

Yeah, please do!

[emmenko]

@gaearon done, I also squashed the commits.

[emmenko]

Damn it, there is a typo...1sec

[emmenko]

Now it should be ok

[gaearon]

👍 thanks!