-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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] Add support for TypeScript 4.1 #23692
Conversation
Details of bundle changes.Comparing: 2f8b294...45dba02 Details of page changes
|
@ldrick It's a great first pull request on Material-UI 👌🏻. Thank you for working on it! |
export default function makeStyles< | ||
Theme = DefaultTheme, | ||
Props extends {} = {}, | ||
Props extends object = {}, |
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.
This change is a breaking one for me
// Type 'boolean' does not satisfy the constraint 'object'.ts(2344)
// ___________________________________🔻
const useStyles = makeStyles<Theme, boolean>(() =>
createStyles({
root: {
display: (show) => (show ? 'block' : 'none'),
}
})
}
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.
Probably, I was using it not as it was designed but still, FYI if it was unintentional
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.
Related to #23706 (comment)
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 bit late to the party, but I wanted to say that we also found this (after a day and a half of searching) to be a breaking change. Based on the docs here, I think lots of people may have implemented a function instead of an object... I'm also not sure I've fully wrapped my head around why it broke us, but that's sort of beside the point. Just wanted to request more caution around things like this being in a patch release even if you could argue people were using it wrong as a justification for why it's "not a breaking change".
I would argue that if it was ever possible to use it wrong, and then you remove that possibility, that you've just made a breaking change, even if that was never the intended usage. /shrug
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.
Just wanted to request more caution around things like this being in a patch release even if you could argue people were using it wrong as a justification for why it's "not a breaking change".
Any type change is potentially backwards incompatible and can therefore be considered breaking. In the DefinitelyTyped community, as well as recommended by TypeScript core members, we don't bump SemVer major changes if patch types or add new features. Otherwise we couldn't apply any change without constantly bumping the major.
): (props: Props) => ClassNameMap<ClassKey>; | ||
): keyof Props extends never // `makeStyles` where the passed `styles` do not depend on props | ||
? (props?: any) => ClassNameMap<ClassKey> // `makeStyles` where the passed `styles` do depend on props | ||
: (props: Props) => ClassNameMap<ClassKey>; |
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.
Those comments should be on lines 14 & 15 I guess 😅
): (props: Props) => ClassNameMap<ClassKey>; | ||
): keyof Props extends never // `makeStyles` where the passed `styles` do not depend on props | ||
? (props?: any) => ClassNameMap<ClassKey> // `makeStyles` where the passed `styles` do depend on props | ||
: (props: Props) => ClassNameMap<ClassKey>; |
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.
here also
This PR adds cherry picks support for TypeScript 4.1 #23633 fixing #23627 in version 4.
Thanks to @eps1lon for creating the original PR.