Allow Differently Typed Selectors

[benshope]

Here is the related issue #264

Right now we have to do typings like this:

const selectorOne = (state: State) => state.something;
const selectorTwo = (state: State) => state.other;
createSelector([selectorOne, selectorTwo], () => ...);

This PR allows us to do typings like this:

const selectorOne = (state: { something: string }) => state.something;
const selectorTwo = (state: { other: number }) => state.other;
createSelector([selectorOne, selectorTwo], () => ...);

Let me know if I should change anything, thanks!

[aikoven]

This is a breaking change since generic arguments changed. We should include both old and new signatures.

[benshope]

@aikoven Yep! Added them back

[aikoven]

I've tested these against a fairly large project with lots of selectors and it worked fine.

There's a failing test that should be fixed. Also, I guess some tests for the new signatures should be added as well.

[benshope]

@aikoven Cool! I fixed the broken tests and added both a failing-case and a passing-case test for both parametric and array selectors

[coveralls]

Coverage remained the same at 100.0% when pulling 5cd0696 on relateiq:typings into c60c851 on reactjs:master.

[codecov-io]

Codecov Report

Merging #274 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #274   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines          15     15           
=====================================
  Hits           15     15

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c60c851...7dad148. Read the comment docs.

[benshope]

Also, I put the Python script I threw together into a Gist - in case someone wants to refer back to this and change the types at some point https://gist.github.com/benshope/9712ed6d725a263467447ac6473502a9

[aikoven]

Nice work @benshope! It's 👍 to me, I hope someone else would also test these in their projects.

[seepel]

@aikoven I tacked on an additional commit to this PR to cover typescript 2.4's new strict generic checks and added a test here: 5ec2b1f

You can see relevant discussion on the topic in this typescript issue: microsoft/TypeScript#17509

[coveralls]

Coverage remained the same at 100.0% when pulling 5ec2b1f on relateiq:typings into c60c851 on reactjs:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 5ec2b1f on relateiq:typings into c60c851 on reactjs:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 5ec2b1f on relateiq:typings into c60c851 on reactjs:master.

[aikoven]

Changing the generic signature of defaultMemoize is a breaking change.

It could potentially be solved via generic defaults, although it would break for users of TS 2.2 and below.

[seepel]

That's fair, I hadn't considered the case where some one might be calling defaultMemoize with the generic:

defualtMemoize<MyFunction>

I've reverted the commit.

[coveralls]

Coverage remained the same at 100.0% when pulling 7dad148 on relateiq:typings into c60c851 on reactjs:master.

[benshope]

@aikoven Hey! Any updates on the status of this?

[aikoven]

@benshope I am so sorry, I've completely lost this thread.

As far as I can remember and see, these changes are backward compatible, aren't they?

Approving.

[benshope]

@aikoven Cool! Yes these changes should be backwards compatible

[ellbee]

Sorry to be so slow to this. As @aikoven has approved, I'll go ahead and commit. Thanks!

[benshope]

@ellbee Thanks!!