Evaluate option to provide keySelector with same args as resultFunc

[toomuchdesign]

A lot of users stumbled upon the question of which arguments are actually provided to keySelector function.

Currently, keySelector functions receive the same arguments as the inputSelectors and the selector itself, but it's easy to mistakenly think that they receive same arguments as resultFunc (which are the result of inputSelectors), instead.

See these threads:

• Key selectors composition #73 (comment)
• Resolver function does not receive same arguments as the final selector function #48

Given that this problem could be alleviated with a better documentation, I'd like to understand pros and cons of adding an option to provide keySelectors with resultFunc results as proposed here by @mbellman.

[landisdesign]

It feels to me like a question of how the caching scheme would be made apparent to the end user of the selector. If I create a selector and I want others to use it, it should be fairly intuitive to understand how it's cached. How would I explain what impacts the cache of the selector?

As it stands now, the end user of the selector could be told, "This selector caches on objectId as long as state doesn't change." How would that sentence look if we need to explain the intricacies of how we got our resultFunc arguments?