Skip to content

Default initializers doesn't work for defaultProps #32402

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

Closed
user753 opened this issue Jul 15, 2019 · 7 comments
Closed

Default initializers doesn't work for defaultProps #32402

user753 opened this issue Jul 15, 2019 · 7 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@user753
Copy link

user753 commented Jul 15, 2019

default initializers defaultProps

Code

interface Props {
  name: string
}

function Greet({ name = "world" }: Props) {
    return <div>Hello {name.toUpperCase()}!</div>;
}
<Greet />

Expected behavior:
According to https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#caveats
it shouldn't have error

Actual behavior:
Has error

TS2741: Property 'name' is missing in type '{}' but required in type 'Props'.

Playground Link:
http://www.typescriptlang.org/play/?jsx=2#code/PTAEGcFMBdQKQMoA1TQPagEQCVIEMBjaTUNAJywAUzIoyA3STAWACg2RQAzPAa0lAAjAJYA7ACZiA5uDbjIBADZ4aoUXgC2tAA6EBuQrADebUNwCuoosLSjQBGnmiQAooshbR0ABQBKAFygeKIAngDcbAC+bGxizmQ8BALUaNrgoCasZupageDQZNJRMaxclta2oADiNDDeRmqaAgC8WADu5IriJJGBKWm+GaZmoDTQ5mR2AOQAEpCKimhTZgDUjVoAdOgAqtrakGQAwnhQfgCEEazR7KwEtvmg4mgaoK0APDWQMKDAAHxAA

There is a workaround

Greet.defaultProps = {name = "world"}

But I would prefer to use default initializers

@MartinJohns
Copy link
Contributor

The documentation you linked refers to a static defaultProps property. You don't have anything like that in your example code. But when you add it, then it will work as expected.

interface Props { name: string }
  
function Greet({ name }: Props) {
  return <div>Hello {name.toUpperCase()}!</div>;
}

Greet.defaultProps = { name: 'World' };

<Greet />

Stackblitz example: https://stackblitz.com/edit/react-ts-bsvjqe?file=index.tsx (ignore the errors, the used TypeScript version is old)

@user753
Copy link
Author

user753 commented Jul 15, 2019

@MartinJohns

The documentation you linked refers to a static defaultProps property.

It has this section

For function components (formerly known as SFCs) use ES2015 default initializers:

function Greet({ name = "world" }: Props) {
    return <div>Hello {name.toUpperCase()}!</div>;
}

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jul 26, 2019
@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@user753
Copy link
Author

user753 commented Jul 29, 2019

@RyanCavanaugh Could you elaborate what is working as intended? And what this line means

For function components (formerly known as SFCs) use ES2015 default initializers:

@RyanCavanaugh
Copy link
Member

Your function has two conflicting pieces of information:

  1. name is optional because it has an initializer
  2. name is required because it's required in Props as specified by the parameter type annotation

TypeScript says that parameter type annotations always win in this situation.

@user753
Copy link
Author

user753 commented Jul 30, 2019

@RyanCavanaugh Thank. So for functional component I need to use defaultProps.

interface Props {
  name: string
}
const Greet = ({name}: Props) => {
    return <div>Hello {name.toUpperCase()}!</div>;
}
Greet.defaultProps = { name: "world" }

and I can use <Greet/> without name property.

But I don't understand what is the point of this example from release notes

function Greet({ name = "world" }: Props) {
    return <div>Hello {name.toUpperCase()}!</div>;
}

It doesn't do anything useful, because I need to use defaultProps.

@user753
Copy link
Author

user753 commented Aug 1, 2019

@RyanCavanaugh any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants