-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[styles] Fix typescript throwing in makeStyles with no props required #14019
[styles] Fix typescript throwing in makeStyles with no props required #14019
Conversation
? string extends T | ||
? true | ||
: false | ||
: false; |
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.
A simpler way to accomplish the same?
export type IsEmptyInterface<T> = {} extends T ? true : false;
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.
That was my first approach too but that would evaluate to true
for object
or Record<"a" | "b", string>
. The first one isn't that problematic since it has no members either but the second one does.
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.
That was my first approach too but that would evaluate to
true
forobject
orRecord<"a" | "b", string>
. The first one isn't that problematic since it has no members either but the second one does.
Strange, the second one shouldn't be true, and it doesn't seem to be in the latest TS.
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.
Funny I did the same but somehow confused the evaluated type. Still true for object though. In that case I would prefer keyof T extends never ? true : false
since it communicates intent better than {} extends T
IMO.
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.
Makes sense to me.
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, but that definition would allow undefined
, null
, void
and never
...
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.
Right. Going to improve coverage and then stick to your approach most likely. object
should be fine in most cases.
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.
@pelotom I extended coverage for IsEmptyInterface
and tried improving readability. I tried your approach in eps1lon@60007f3 but this doesn't work in its current form since it completely disables type checking for props.
: false | ||
: false; | ||
|
||
type Or<A, B> = A extends true ? true : B extends true ? true : false; |
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.
We might want to use a library like typelevel-ts
instead of reinventing all our own combinators.
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.
Definitely. I would defer that to a different PR though since we have plenty of unrelated candidates for this (Pick
, IsAny
?) and I want to to have a look at different options. I for one only used utility-types
.
I would like to do a release tomorrow. Is this pull-request ready to be merged? |
Good from my perspective. |
Right now typescript infers
Props
toany
inStyleRulesCallback
but to{}
inStyleRules
if props are not used. I'm not sure if this is actually a typescript bug but it's fixable in our codebase.Closes #14018