reselect: 4.1.3 fix breaks createSelector() with more than one Parameter

You fixed https://github.com/reduxjs/reselect/issues/548 in 4.1.3 but now a createSelector() breaks with the same error message - it worked with 4.1.2 before.

const some = createSelector(
    (a: number) => a,
    (_a: number, b: number) => b,
    (a, b) => a + b
)

export const test = some(1, 2)

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 11
Comments: 33 (18 by maintainers)

Most upvoted comments

Sorry to barge in on a closed issue but could we at least document somewhere that reselect requires strictNullChecks to be true? I say this as someone who woke up to all my builds breaking due to redux-toolkit automatically using the new version causing errors in a lot of selectors.

I realize its not feasible to handle every error caused by non-standard setups but it’s still a bit unintuitive that a TS setting that handles null will somehow cause a problem with the number of parameters in a function. I also think that a certain amount of users will turn off typescript strict mode without realizing this defaults strictNullChecks to false.

doarrison on Nov 18, 2021

@Sincerite As of 4.1.x, Reselect needs you to actually provide meaningful types for all arguments in all input selectors. Otherwise it can’t figure out what the final argument types should be for the selector it’s about to create. Like, say, (_: RootState, id: string) => id.

markerikson on Dec 22, 2021

@doarrison Yeah, if someone wants to add a note on that to the README we can merge it.

That said, I honestly see strictNullChecks: true (and really strict: true in general) as a required baseline for any meaningful TS usage. We’ve seen multiple cases over in the RTK repo where people reported “type errors” of some kind, and it turned out that they had strictNullChecks turned off. So, it’s not like Reselect is the only library where turning that flag off is going to create problems in your own code.

Having that flag off both changes how TS is going to interpret library types, and opens up holes in your code. Now, I’m not at all one of those people who goes around saying that “a single use of any will cause your codebase to burst into flames”, and I am perfectly fine with pragmatic use of TS types. any and // @ts-ignore are perfectly valid tools to use.

At the same time, switching that flag off is weakening the typechecks that you do have, and leads to these kinds of problems. I would much rather keep strictNullChecks on, and explicitly put a // @ts-ignore or a type $FixTypeLater = any to acknowledge that I’m having to work around the type system, then leave it off and have a change in behavior.

So, my advice would be to turn on strict: true so that TS is doing correct analysis, and annotate your code to work around any issues that come up.

markerikson on Nov 18, 2021

(but for the record your third input selector should be (state: RootState, semesterId: string, subjectId: string) => subjectId - you’re missing the second parameter)

EskiMojo14 on Dec 5, 2023

Works again with 4.1.5 without strictNullChecks. Thanks a lot!

JMS-1 on Nov 25, 2021

Fails with strictNullChecks: false: Playground Link Passes with strictNullChecks: true: Playground Link

DefinitelyTyped packages are also only tested with strictNullChecks i.e. it’s expected to run into issues if strictNullChecks are disabled.

eps1lon on Nov 17, 2021

I just tried wrapping the inputs in an array in that repro project, and it didn’t make a difference.

But, removing the ExpandItems<> line did seem to let things build.

Maybe that’s the issue here?

I’ll have to investigate further this evening.

markerikson on Nov 17, 2021