-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1953: Avoid non-null assertions for WhoAmI #1954
base: main
Are you sure you want to change the base?
Conversation
4e9723a
to
a67a04a
Compare
type UseWhoAmIReturn = WhoAmIContextType & { me: WhoAmIQuery['me'] } | ||
|
||
export const useWhoAmI = (): UseWhoAmIReturn => { | ||
const { me, ...context } = useContext(WhoAmIContext) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should throw an error, if me
is null.
Also, I think it's not necessary to create a new object, we can just return whatever useContext(WhoAmIContext)
returns.
I am also a bit confused about the @ts-expect-errror
on line 58. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should throw an error, if
me
is null.
👍
Also, I think it's not necessary to create a new object, we can just return whatever
useContext(WhoAmIContext)
returns.I am also a bit confused about the
@ts-expect-errror
on line 58. 🤔
Typescript seems to have problems when checking object properties for nullish values and raises an error in that case. This is why we have the @ts-expect-error
. Same for directly returning the context without destructuring/creating a new object like this:
const context = useContext(WhoAmIContext)
if (context.me === null) {
throw new Error('')
}
// TS 2322: Type null is not assignable to type ...
return context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this seems to be a known limitation of typescript 🤔 . Probably, it's better to do
const context = useContext(WhoAmIContext)
if (context.me === null) {
throw new Error('WhoAmI context is not available')
}
return context as UseWhoAmIReturn
(and below we can probably do value as WhoAmIContextType
instead of ignoring the error)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I really don't like typecasts if we can avoid them, do you think that is a better solution here instead of destructuring the object in this case? I agree for below, doesn't really matter if we have a @ts-expect-error
or a typecast, but looks cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could also abstract away this typecast in a type guard like
const hasProp= <
P extends PropertyKey,
O extends { [p in P]: unknown }
>(obj: O, p: P): obj is (O & { [p in P]: NonNullable<unknown> }) => obj[p] !== undefined && obj[p] !== null
export const useWhoAmI = (): UseWhoAmIReturn => {
const context = useContext(WhoAmIContext)
if (!hasProp(context, 'me')) {
throw Error("WhoAmI context is not available")
}
return context
}
Maybe, that's the cleanest, but slightly overwhelming solution...
a67a04a
to
447374e
Compare
Short Description
Avoid non-null assertions for who am i by creating a hook.
Proposed Changes
Side Effects
me
is actually not null, so when a user is logged inTesting
Ensure that everything still works.
Resolved Issues
Fixes: #1953