[couchand]

I definitely wasn't recommending that usage, just illustrating what it might look like. I personally think it looks much cleaner, which I would call an advantage.

I've considered the first point, but hadn't thought about the second and third. I'm guessing the last point isn't a concern if you're using class properties for those?

Given all this, if you were redesigning the API today, would you now make connect take the component as the first parameter instead?

[acemarke]

No. The reason why it's written as not just a HOC, but a curried-ish function is so that you could potentially reuse the "connection" definition for multiple components:

    const SpecificConnection = connect(mapState, mapDispatch);
    const ConnectedFirst = SpecificConnection(FirstComponent);
    const ConnectedSecond = SpecificConnection(SecondComponent);

Admittedly, I suspect that use case isn't popping up very often. Most of the time what I see is that a given component type is only connected once, and a given connection setup is only used with one component. I also don't remember seeing specific comments by Dan or Andrew saying that's why it's written this way - I'm inferring the intent from the API definition. Still, it's a potentially useful capability in the API, so no reason to throw it away.

[couchand]

Theoretically that could be useful, but I've also never seen connections used this way. I have seen components connected in more than one way, but of course that's no easier with the curried style. And, I'd point out, if someone actually wanted to share the configuration, it's trivial enough to write:

  const SpecificConnection = (Component) => connect(Component, mapState, mapDispatch);

Not that I'd argue against currying generally -- it's only that it turns out to be a little awkward here with the various optional parameters to connect, and also that the connection setup in practice seems to be tightly coupled to the connected component.