[prop-types] Throw `is missing in props validation` when reassign `this.props` to `props`

[hellocreep]

Hello!

Got an strange behavior when assign this.props to props, it will throw an error message is missing in props validation.
And seems it only happens when use const props = this.props.

eslint: 4.0.0
eslint-plugin-react: 7.1.0

This piece of code will throw an error.

const Card = React.createClass({
  propTypes: {
    isReturning: PropTypes.bool,
    date: PropTypes.string
  },
  render() {
    const props = this.props;
    return (
      <div>
          {props.isReturning}
          {props.departureDate}
      </div>
    )
  }
});

error  'isReturning' is missing in props validation    react/prop-types
error  'departureDate' is missing in props validation    react/prop-types

This is no error.

const Card = React.createClass({
  propTypes: {
    isReturning: PropTypes.bool,
    date: PropTypes.string
  },
  render() {
    const {isReturning, departureDate} = this.props;
    return (
      <div>
          {isReturning}
          {departureDate}
      </div>
    )
  }
});

This is no error.

const Card = React.createClass({
  propTypes: {
    isReturning: PropTypes.bool,
    date: PropTypes.string
  },
  render() {
    return (
      <div>
          {this.props.isReturning}
          {this.props.departureDate}
      </div>
    )
  }
});

Even this is no error.

const Card = React.createClass({
  propTypes: {
    isReturning: PropTypes.bool,
    date: PropTypes.string
  },
  render() {
    const test = this.props;
    return (
      <div>
          {test.isReturning}
          {test.departureDate}
      </div>
    )
  }
});

[ljharb]

I would instead recommend const { isReturning, departureDate } = this.props.

[ljharb]

(That said, this sounds like something worth fixing)

[dustinsoftware]

Has this already been fixed? I can't repro this issue with the latest commits on master.

[hatched]

After updating to eslint@4.1.1 and eslint-plugin-react@7.1.0 I am still able to reproduce the issue using the provided code.

Converting it to use extends has also resolves the issue:

class card extends React.Component {
  render() {
    const props = this.props;
    return (
      <div>
        {props.isReturning}
        {props.departureDate}
      </div>
    );
  }  
}

card.propTypes = {
  departureDate: React.PropTypes.string,
  isReturning: React.PropTypes.bool  
};

So it appears to be limited to assigning const props = this.props when using createClass.

[ljharb]

createClass is deprecated; so you shouldn't be using it anyways.

That said, the bug should still be fixed.

[hellocreep]

Thanks @hatched and @ljharb , I think that makes sense to me.

[dustinsoftware]

I was able to repro this behavior, but it looks like it might be by design.

Passes:

    {  
      code: [
        'var Hello = React.createClass({',
        '  propTypes: {',
        '    testing: PropTypes.string.isRequired',
        '  },',
        '  render() {',
        '    const props = this.props;',
        '    return <div>Hello {props.testing}</div>;',
        '  }',
        '});'
      ].join('\n'),
      settings: {
        react: {
          createClass: 'createClass',
        }
      }
    }

Fails if createClass is removed from settings.react.

This appears to be because, during the unit tests, the default function name for creating React components is set to createReactClass. If the function name used to create the component doesn't match what's defined in settings, the linter thinks that it's in a stateless function when seeing a reference to a variable named props because of this line. This causes the false error to appear - it's saying the render function doesn't have propTypes declared on it (which is true)

[ljharb]

This seems right.

However. Perhaps createClass is a better default value for that pragma.

[alexkrolick]

Also reproducible if you destructure this:

const { props, someMethod, someAttr } = this;

Sometimes it is nice to keep props namespaced.

Anyways, here's the line: https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unused-prop-types.js#L110

This would be fixed if props.yyy was allowed in class contexts as well as stateless components

[ljharb]

props.yyy should only be allowed in class contexts if props can be statically determined to be this.props.

[robguy21]

Leaving my reduced example here...

type PropsShape = {
  // error  'data' PropType is defined but prop is never used  react/no-unused-prop-types
  data: Array<*>,
}

class List extends React.Component<void, PropsShape, void> {
  // .. some stuff up here that does not use this.props.data
  render() {
    const that = this;
    return (
      <div>
        {
          that.props.data.map(v => <span>{v.id}</span>
        }
      </div>
    );
  }
}

(Above is just for demo purposes.)

If anyone could point me in the direction of solving this issue I'd love to get involved, use this eslint extensively and might be time to at least try and help out where I can.