Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow skipping prop-types validation when not declared #846

Merged
merged 4 commits into from
Oct 1, 2016

Conversation

pfhayes
Copy link
Contributor

@pfhayes pfhayes commented Sep 16, 2016

Adding the prop-types rule can be a daunting task for
projects that have not been consistent about using prop
types to begin with.

This allows users to slowly opt-in to prop-types validation
by only erroring on "incomplete" propTypes declarations.

Adding the `prop-types` rule can be a daunting task for
projects that have not been consistent about using prop
types to begin with.

This allows users to slowly opt-in to prop-types validation
by only erroring on "incomplete" propTypes declarations.
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind also adding tests for SFCs, and class-based components? In addition, please make sure to have test cases for class-based components for both "static class properties" and "post-definition static assignment". Thanks!

@pfhayes
Copy link
Contributor Author

pfhayes commented Sep 17, 2016

@ljharb sure thing - let me know if this is what you had in mind

}, {
code: [
'class Hello extends React.Component {',
' static get propTypes() {',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually this would be static propTypes = () => { - i don't think propTypes is expected to be anything but a data property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied how the other static propTypes were declared in this file. upon closer inspection, this file is inconsistent in how it declares static proptypes. I see three different types:

static get propTypes() {
static propTypes = {
static propTypes: {

do you think I should introduce a fourth type? i'm also happy to consolidate them but I think that is outside the scope of this PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm not sure why we have the getter version, and the "fourth" type is in fact the most standard. The third type there isn't actually valid because of the static keyword, but I think you mean its use in React.createClass, which is fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not worry about consolidating them in this PR, but please do add a Hello.propTypes = { … } variant.

}, {
code: [
'class Hello extends React.Component {',
' static get propTypes() {',
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure thing - I've added that as an additional case

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM other than my one comment

@@ -179,10 +182,12 @@ module.exports = {
* @returns {Boolean} True if the component must be validated, false if not.
*/
function mustBeValidated(component) {
var isSkippedByConfig = (typeof component.declaredPropTypes === 'undefined' && skipUndeclared);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These parens are unnecessary. It also might be better to check skipUndeclared first?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!

@yannickcr yannickcr merged commit b464cf1 into jsx-eslint:master Oct 1, 2016
@yannickcr
Copy link
Member

Merged, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

4 participants