- Notifications
You must be signed in to change notification settings - Fork4.3k
[Basic] Improve the class component defaultProps example#103
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
[Basic] Improve the class component defaultProps example#103
Uh oh!
There was an error while loading.Please reload this page.
Conversation
In the current example, we have a type definition for props but do notmake use of it for defaultProps. This can lead to a mismatch betweendefaultProps and props.
swyxio commentedApr 8, 2019
good eye! thanks very much! |
VanTanev commentedApr 8, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@sw-yx Actually, I just checked, and the caveat that is stated under "Typescript 2.9 and earlier" still applies - Another approach would be to use: staticdefaultProps:Pick<Props,'name'>={name:'world'}` What do you think? |
ferdaber commentedApr 9, 2019
A good way of working with typeProps=typeofMyComponent.defaultProps&{age:number}classMyComponentextendsComponent<Props>{staticdefaultProps={name:'world'}} |
swyxio commentedApr 9, 2019
o shit lets do that instead! much nicer. |
VanTanev commentedApr 9, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I ran into a case where the // in a separate fileinterfaceModelValues={title:stringdescription?:string}// in a custom formik formtypeProps={onSubmit:(values:ModelValues,actions:FormikActions<ModelValues>)=>voidinitialValues:ModelValues}classModelFormextendsReact.Component<Props>{staticdefaultProps:Pick<Props,'initialValues'>={initialValues:{title:''description:''}}render(){ ...}} The reason I want to have a type definition directly on |
RiaanWest commentedJan 24, 2020
This has been merged, so not sure if y'all will see this, but: This seems to now be possible if you make use of an interface for props: |
swyxio commentedFeb 2, 2020
i see you@RiaanWest. wanna PR something? |
ferdaber commentedFeb 2, 2020
This will break exporttypeIconSize='small'|'regular'|'medium'|'large';interfaceIconPropsInterface{icon:string;size?:IconSize;}exportclassIconextendsComponent<IconPropsInterface>{staticdefaultProps:IconPropsInterface={icon:'',size:'regularrr',<--Throws:Type'"regularrr"'isnotassignabletotype'"small" | "regular" | "medium" | "large" | undefined'.ts(2322)}}constmyIcon=<Icon/>// this will not throw an error even though `icon` is required, |
RiaanWest commentedFeb 17, 2020
Thanks for pointing this out@ferdaber - great point. I wasn't aware of that! |
Uh oh!
There was an error while loading.Please reload this page.
What cheatsheet is this about? (if applicable)
Basic cheatsheet
--
In the current example, we have a type definition for
Propsbut do not make use of it fordefaultProps. This can lead to a mismatch between the actual fields indefaultPropsand what thePropstype defines.Adding an explicit
Partial<Props>type todefaultPropsseems like good example code.