Experimental features?

[hornta]

I have made a rule that enforces you to specify propTypes and defaultProps as static class properties. I don't know if I should make a PR for this since it depends on the experimental feature. We are planning on using it in our codebase, which is large. Would it be of interest here?

INCORRECT
class MyComp extends Component {} MyComp.propTypes = {}; MyComp.defaultProps = {}

CORRECT
class MyComp extends Component { static propTypes = {}; static defaultProps = {}; }

[ljharb]

I think it'd be useful if it was configurable both ways - ie, i could use it to require OR forbid implementing them as static class properties.

Also, don't forget displayName and contextTypes.

[hornta]

Yes. I can implement displayName and contextTypes as well.
Currently I have named the rule use-static-proptypes. But I don't really think that is a good name since it also incorporates defaultProps, and now, contextTypes and displayName.

And having one rule for each feels like it would be a bit tedious.
use-static-proptypes
use-static-defaultprops
use-static-displayname
use-static-contexttypes
Do you have any name suggestions?

[ljharb]

How about react/component-static-property-style?

[hornta]

Sounds good!

So having "always" set for "react/component-static-property-style" forbids object property notation style and forces you to provide them as static class properties?

[ljharb]

not "always" because that isn't clear what it means.

I'd expect it to take this schema:

1. a string, either "static public field" or "property assignment" (the names can be bikeshed)
2. an object that has keys for propTypes, defaultProps, contextTypes, and displayName, that takes the same string as above - which can override the default "everything mode" set above.

[dmason30]

@hornta Did you ever implement this rule in your ruleset? Although we would want to enforce the opposite :"forbid implementing them as static class properties."

[hornta]

No I have not. You can give it a go :-)

[dmason30]

@hornta I have done the rule part in #2193 - not fixable yet though