Improve GenerateForgotPasswordEmailHTML
(and similar) TS types
#10441
HappyEmu
started this conversation in
Feature Requests & Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When you add
auth
to a collection, you can configure for example thegenerateEmailHTML
hook. The types for these kind of functions are really not helpful:For example, when I have a
nurses
collection, I cannot assert the type ofuser
correctly, becauseargs
is allowed to beundefined
. So code like this:Will infer type
any
for thenurse
binding. The most obvious thing to do would be to add the type to theuser
parameter:But that does not work since the whole
args
and indeed{ user }
can beundefined
as by the types mentioned above. So I'd have to writeto make the consumer code compatible with the types. But now
nurse
is inferred toany
again, since the wholeargs
can beundefined
. Apparently in TS,const { foo } = undefined
causesfoo
to be inferred asany
, and notnever
even though that line throws an error.So in order to write correct TS code, where
nurse
has the appropriate type, I'd have to writewhich I hope everybody agrees is nothing anybody should need to write given the assumption that indeed
args
or any of its parts{req, user, token}
can ever be nullish, given thatgenerateEmailHTML
is called like this:where neither
req, token, nor user
can be nullish. Even if they could benull
orundefined
, what would be the fallback return value if any of these are missing?In conclusion: Why are these function parameters nullable?
Beta Was this translation helpful? Give feedback.
All reactions