We are using flow in our project, also for typing the properties. And it seems as if the default-props-match-prop-types rule doesn't recognize flow types. Is that possible? Is that something that could be easily implemented?
hmm - in flow, do you just use default arguments?
This rule isn't actually checking types; it's just checking that defaultProps has a matching entry in propTypes when the propType isn't required. Would you want it to enforce default arguments on any non-required prop?
I know that it is not about checking types, I actually want what you've described, but instead of checking if there is a matching entry in propTypes it should use the flow types instead. I'll paste an example:
type Props = {
size: number,
value: Point,
active: boolean,
onClick?: (value: Point) => void,
arrowDirection?: 'left' | 'top-left' | 'top' | 'top-right' | 'right' | 'bottom-right' | 'bottom' | 'bottom-left',
};
export default class ImageFocusPointCell extends React.PureComponent<Props> {
static defaultProps = {
active: false,
showArrow: true,
};
// other code not important for this rule
}
The showArrow key in the defaultProps doesn't exist in the flow type, and it would be nice if this rule (or another rule, if they are not easy to combine) would give me a hint. This often happens for us during refactorings / reviews, and can easily be overseen.
Gotcha. That seems like a reasonable enhancement for this rule.
I faced the same issue today but only with functional (stateless) components.
Stateless component:

Stateful component:

@PoliakovMaksym the stateful component error seems correct to me; you're not using anything there that requires it be stateful.
@ljharb the issue is not with the prefer-stateless-function. This error is totally fine. I showed it to point out that it is not the default-props-match-prop-types error. The thing is that default-props-match-prop-types is present in stateless component and absence in stateful one with the exact same code (except stateless vs stateful differences)
gotcha, thanks for clarifying.
what's the status of this issue?
Is there any progress on this? We use this quite extensively in our projects.
Any updates? This would really help us. Thanks.
it would be really nice to have this feature. thanks ;)
may i ask how everyone is getting around this issue? Are you guys still using flow for stateless components?
Still no movement here?
The status of this issue is that it's labeled "help wanted", and nobody has submitted a PR for it yet.
For all those folks that'd like to see this land, please feel free to take a crack at fixing it :-) The maintainers of this project are humans and do not have infinite time at their disposal.
@ritchieanesco I just disable that eslint rule 馃ぃ
You could just use this configuration for rule:
"react/default-props-match-prop-types": ["error", { "allowRequiredDefaults": true }]
This will allow you to have defaultProps for not optional (required) props without warning and also this will work fine with flow, because for flow prop which has corresponding default prop is not optional prop.
One note on the suggestion by @Elf2707 - that appears to work so long as your flow types are in the same file as your component; it does not appear to work if you have flow PropType in another file (like a ./types.js) and import it (import type { ButtonProps } from './types');.
"react/default-props-match-prop-types": ["error", { "allowRequiredDefaults": true }]
works in most cases for me, but it doesn't expand type spreads, e.g.
export type SharedProps = {|
disabled: boolean,
|};
type Props = {|
...SharedProps,
focused?: boolean,
|};
class Foo extends React.Component<Props> {
static defaultProps = {
disabled = false;
};
};
eslint produces the following error:
error defaultProp "disabled" has no corresponding propTypes declaration
Most helpful comment
You could just use this configuration for rule:
"react/default-props-match-prop-types": ["error", { "allowRequiredDefaults": true }]
This will allow you to have defaultProps for not optional (required) props without warning and also this will work fine with flow, because for flow prop which has corresponding default prop is not optional prop.