bug(store) add explicit overloads for createSelector #3354
Conversation
✅ Deploy Preview for ngrx-io canceled.Built without sensitive environment variables
|
| ...args: [...slices: Selector<State, unknown>[], projector: unknown] & | ||
| [ | ||
| ...{ [i in keyof Slices]: Selector<State, Slices[i]> }, | ||
| (...s: Slices) => Result | ||
| ...slices: { [i in keyof Slices]: Selector<State, Slices[i]> }, | ||
| projector: (...s: Slices) => Result |
There was a problem hiding this comment.
I added names to clarify what these tuples represented.
There was a problem hiding this comment.
Nice, I didn't know we could do that! 🤩
There was a problem hiding this comment.
It's quite handy bc variadic tuple types become quite cumbersome looking quickly 😅
There was a problem hiding this comment.
It seems like the case of the issue isn't resolved with this fix, but I can't figure out how to do it otherwise... This should cover most of the cases imo, which is better than nothing.
const state: {first : string} = { first: 'state' };
const getData = <T>(d: T): T => d;
const returnState = () => state;
const selector = createSelector(returnState, getData);
expect(selector(state).first).toEqual('state');
Also, would it be possible to move the tuple version to the top and add a @deprecated annotation to the re-added selectors?
This seems fine for the selectors in the example app but since I don't have a reproduction of the issue, I can't confirm that this works correctly for the deprecated cases.
@mattlewis92 would it be possible if you confirm this fix in your repo?
This appears to verify that the case presented in the issue works: playground. |
The order cannot be changed, as then the variadic signature will always match. This error is demonstrated in this playground. |
Sure thing, I just checked it in our repo with this change and it now all builds correctly! 🙌 |
There was a problem hiding this comment.
Thanks @david-shortman , and also thanks @mattlewis92 for the verification.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Closes #3268
What is the new behavior?
Does this PR introduce a breaking change?
Other information
I only added explicit overloads for
createSelectorwith variadic "slice" arguments, because only that signature failed due to the problems identified in #3268. The signature that uses an array for the "slices" does not fail.