Rule Proposal: no-unused-prop-types

[Mitch Lillie]

There is a lot of discussion in eslint-plugin-react about the no-unused-prop-types rule. It seems to cause plenty of users issues, but especially Redux users, as it does not make an attempt to check mapStateToProps, mapDispatchToProps, or mergeProps for props that are used. This rule should completely replace react/no-unused-prop-types.

The following would be an example of correct code for this rule:

import React, { Component } from 'react';
export const mapStateToProps = (state, ownProps) => ({
  myData: getMyData(state, ownProps.myProp),
});

export class MyComponent extends Component {
  render = () => (
    <MyOtherComponent
      myData={this.props.myData}
    />
  )
}

MyComponent.propTypes = {
  myProp: PropTypes.string.isRequired
};

export default connect(mapStateToProps)(MyComponent);

[Jordan Harband]

You may be able to use eslint-rule-composer for this, and avoid having to re-implement the bulk of the rule.

[DianaSuvorova]

Interesting, I haven't heard of eslint-rule-composer- seems like a very handy until. let me see if having no-unused-prop-types rule on redux side can solve problems people have with the react's version of it.

[DianaSuvorova]

looks like it should pretty straightforward to correctly decide on props usage for the example above (with the help of eslint-rule-composer).
Although, in my experience it is very common practice to have component and redux container in separate files. @ljharb do you know if it is possible/good idea to write eslint rule potentially spanning multiple files?

[Jordan Harband]

The only plugin that i know looks at multiple files is the import plugin - and it only does that to build up a dependency map.

I don’t actually think we have any code at Airbnb where the redux container and the component it wraps are separate; either way, i think that’s not something you need to handle in the first iteration.

[DianaSuvorova]

@ljharb , @MitchLillie I am planning to merge #31, lmk if you have any comments.