Coverage decreased (-1.09%) to 98.907% when pulling 484c1e7 on key-selector-composition into 3422d90 on master.

Before considering this PR mergeable, I'd like to address the following issue. I write it down here to not keep everything floating in my head.

keySelector argument

implicit keySelector vs. explicit extraKeySelector

In an early iteration, keySelector was provided as argument to keySelectorCreator function (along with inputSelectors and resultFunc) and used to produce an optional extra chunk of cache key:

export const getMyData = createCachedSelector(
  // inputSelectors and resultFunc
)(
  keySelector,
  {
    keySelectorCreator: ({keySelector}) => {},
  }
);

I tried avoiding this implicitness by not considering keySelector when providing a keySelectorCreator and directly supplying an extraKeySelector prop

export const getMyData = createCachedSelector(
  // inputSelectors and resultFunc
)(
  undefined,
  {
    keySelectorCreator: new KeySelectorCombiner({
      extraKeySelector: () => 'extra'
    }),
  }
);

Even though I find this solution more straightforward, the need of passing some useless keySelector argument looks suboptimal in terms of design

TS Typings

On top of that if keySelector is considered required in TS typings, and make it optional implies considerable typing declarations changes.

A new polymorphic signature for createCachedSelector?

I considered providing a second optional signature for createCachedSelector consisting of a single option object so that the 2 following example produce the same result:

// Current default API
(
  keySelector,
  {...options}
)

// "option only" API
(
  {
   keySelector,
    ...options,
  }
)

The signature consisting of keySelector function + option object could be removed in favour or keySelector function (simple mode) OR option object (advanced).

Even if it solves the optional cacheKey API issue, I'm not sure at all that introducing polymorphic API's is a good idea on the long run.

Of course such a signature would also increase types complexity.

Release options.keySelectorCreator first (#82)

Since finding a solution to all this might take time, I'm considering making a first release with the only part of this PR which looks solid: options.keySelectorCreator.

options.keySelectorCreator would expect a function with the following signature.

type KeySelectorCreator<S, C, D> = ({
  inputSelectors: D,
  resultFunc: C,
  selector: S,
}) => KeySelector<S>

Users might temporarily provide their own keySelectorCreator implementation.

Most of the open points of this PR are now solved:

• v3.3.0 enabled keySelector composition shipping keySelectorCreator option plus documentation.
• v3.4.0 introduced single argument signature that alleviates the keySelector vs. explicit extraKeySelector issue

We'll open a new PR in case we decided to include a KeySelectorCombiner utility.