Eslint-plugin-react: require-default-props natively

[NullDivision]

Given the following example:

const Container = ({ name = 'Lucy' }: { name?: any }) => <div><span>{name}</span></div>;

Understandably the above code does not use the defaultProps assignment but I'm wondering if this should be added as an acceptable case considering that under ES6 destructuring rules this should be a perfectly valid case of property assignment.

[ljharb]

It should not; defaultProps are not the same as ES6 destructuring (although both only apply to undefined). In addition, defaultProps provides information to React, which handles the defaulting; by using ES6 defaulting, you're depriving React of the ability to optimize based on it.

[NullDivision]

I understand what you're saying but from the React source I remember only a couple of things happening to defaultProps:

• check for getDefaultProps (not the case for arrow function and I doubt anyone would have a reason to coerce it)
• check for defaultProps property assigned to constructor
• check for any illegal/reserved properties (eg. key) in the defaultProps object

Advantages of destructuring:

• no reason for coercion
• doesn't require React to loop through defaultProps on every update
• no side-effects
• respects JS/ES6 standards implementation

Maybe I'm missing what you mean by optimize. AFAIK React doesn't do component optimization on pure functions.

It could be an option for the rule like:

"react/require-default-props": [2, { allowImplicit: true }]

[ljharb]

666 may be relevant here.

[NullDivision]

The issue is indeed related in a manner as it is the exact opposite of what I want. Also the rule proposal is aptly named prefer-default-props, not require. The scope of require-default-props should not be to enforce the use of the defaultProps property (note: in its current state the rule clashes with several other rule libraries as is my case with immutable/no-mutation)

The scope of the rule should be to assign a default value in order to prevent undefined property values. Am I correct in this assumption?

[ljharb]

My interpretation of the original intent of the rule is to require a defaultProps entry for each non-required propType, not to prevent undefined property values (especially since undefined is a valid defaultProps value).

[NullDivision]

I see your point. Still wondering if there's a way to circumvent the use of default props, especially if developers use Flow instead of propTypes.

[ljharb]

Flow is not a complete replacement for PropTypes, as there's many things custom propType validators can do that Flow can't. I don't see the issue in using both Flow and defaultProps.

[mrchief]

@ljharb for functional components, seems like the preferred way is to use ES6 defaults. See this https://github.com/facebook/flow/issues/7467

[mrchief]

@ljharb disregard my earlier comment. I'm just catching up on this https://github.com/yannickcr/eslint-plugin-react/issues/1009. That thread seems painful to repeat here. :)