Revaluate default props behavior in JSX functional components

[svpace]

Regarding the recognition of default initializers as part of type checking on functional components, I believe issues #32402 and #31247 should be reevaluated in the light of #34547 and the potential deprecation of defaultProps, and also on the own merits of both issues.

TypeScript Version: 3.7.5

Search Terms:
defaulProps, FunctionalComponent, JSX, React

Code
View issues #32402 and #31247

Expected behavior:
View issues #32402 and #31247

Actual behavior:
View issues #32402 and #31247

Playground Link:
View issues #32402 and #31247

Related Issues:
Issues #32402 and #31247 =D

[DanielRosenwasser]

This is pretty open-ended - what re-evaluation did you have in mind?

[svpace]

Whoa.. that was fast. Thank you for that.

Both issues were closed on a "working as intended" basis (although only #32402 was labelled). Given the following code extracted from #31247:

interface Props {
  name: string;
  optional: string;
}
const Component = ({ name, optional = "default" }: Props) => (
  <p>{name + " " + optional}</p>
);
const Test = () => <Component name="test" />;

IMHO it is safe to say that both, the "Component" function definition and the "Props" interface agree that "optional" should not be undefined. Even if rejecting "Test" definition is really working as intended, it is at least a bit surprising.

Although there are workarounds, including using "defaultProps", I believe it is undesirable to have to change a theoretically type safe code only to satisfy the type checker.

Now, since #34547 deals with, among other things, the possible deprecation of "defaultProps", it seemed like a good opportunity reevaluate supporting default initializers as an alternative, and a much less surprising solution, to default props on functional components.

Sorry for the long reply.

Regards

[svpace]

It seems #27425 also related