Move combiner function before selector functions for type safety

[nickserv]

In JavaScript, spread parameters are only valid as the last parameter of a function to prevent ambiguity. Type checkers like TypeScript and Flow rely on this assumption as well for checking function argument types.

Unfortunately, even though TypeScript (as of version 3) and Flow support spread parameters, they cannot be used with Reselect's incorrect spread argument order. The combiner function is last, when it should be first so the selector functions can be a final spread parameter. This is necessary to take full advantage of all possible usages of Reselect besides the argument combinations hard coded in the TypeScript and Flow definitions, and also solves semantic confusion where Reselect has a different argument order for variable argument orders than most JavaScript APIs.

Alternatively, we could simply remove the API signatures that don't use the Array of selector functions. This would not break any code that is only using Arrays of selector functions.

[dcurletti]

+1 the benefits of this would also include a better typing signature.

const fooSelector = (state: RootState) => state.foo;

const barSelector = createSelector(fooSelector, foo => {
  fooBar: foo.bar;
});

Rather than barSelector being inferred, I want to be able to declare its return value without having to pass in: RootState, Foo beforehand.

[AlexeiDarmin]

I reached the same conclusion to move the combiner as the first function but didn't say anything since I figured it would be too disruptive to the library. I'm all for this.

This also could allow for some better features moving forward supposing the spread operators gets better and better support by TypeScript

[nickserv]

TS now supports mapping tuples, including arguments. This might be enough of a workaround to get strong typing on the current API, but it would still be much easier and simpler to fix the location of the combiner function or remove the other signatures.

[markerikson]

Based on the changes in #486 and #513 , I think this is now obsolete. We can keep the combiner last and still get perfect inferred types, no API changes needed.