Document that rules dealing with prop types recognize static types, too #2546
Conversation
|
I realized it would be a good idea to document the same for other rules like |
ljharb
force-pushed
the
prop-types/static-types
branch
from
1ed251f to
3ef1208
Compare
docs/rules/prop-types.md
Outdated
|
|
||
| It can warn other developers if they make a mistake while reusing the component with improper data type. | ||
| You can provide types either in runtime types using [PropTypes] or statically |
There was a problem hiding this comment.
let's reword this so it doesn't implicitly discourage using both - even when using static types, using PropTypes is recommended, because they can check many more things than static types can.
There was a problem hiding this comment.
Ok, I decided to simply use "and/or" instead of "or", that sounds fine to me. Let me know if you want something different.
silvenon
force-pushed
the
prop-types/static-types
branch
from
3ef1208 to
9a4baf6
Compare
There was a problem hiding this comment.
Ok, I think I found all the rules which recognize static types and I added a message to make this clear. Let me know if you don't like the blockquote formatting, one alternative could be to use horizontal rules, but that would maybe be too dramatic.
I also tried to use more agnostic language instead of "propTypes", and I sprinkled a few examples with static types.
silvenon
changed the title
| return <div>Hello {name}</div>; | ||
| // 'name' type is missing in props validation |
There was a problem hiding this comment.
I tested this and it seems that currently rule prop-types does not report on props with typescript type annotation, can you confirm or refute this?
Off topic: In my opinion rule prop-types should not report on props with ts/flow type annotation, since type-checker already excelled in pointing out usage of undeclared properties and that eslint-plugin-react also reporting the same thing just adds noise.
There was a problem hiding this comment.
I only think you're right if the propType exactly matches the type annotation - and since propTypes are more powerful than static types in many ways, this will often not be the case.
These examples use `createReactClass` a lot, which is legacy at this point. I'm modifying examples to primarily use function components because those are the ones people are using most often today. Other ways of defining a component are just here to show that this rule recognizes them, too. Also, document that rules like `prop-types` and `require-default-props` recognize static types, too
ljharb
force-pushed
the
prop-types/static-types
branch
from
9a4baf6 to
c481a26
Compare
|
I apologize for not finishing this PR 😕 I hope you managed to fix problematic parts. |
In a separate commit I cleaned up examples to be a bit more modern, preferring function components, so they are easier to read, then documented that this rule isn't only for
PropTypes, but that it accepts static types, too.