False positives for [no-unused-prop-types] when props is assigned to a local variable

[laumair]

class App extends Component {
  static propTypes = {
    notifications: PropTypes.array.isRequired
  };

  customizeNotifications() {
    const props = this.props;

    return props.notifications.map((notification) => `foo${notification}`);
  }

  render() {
    const notifications = this.customizeNotifications();

    return (
      <View>
        {notifications.map((notification) => <Text>{notification}</Text>)}
      </View>
    );
  }

Eslint complains about notifications prop as unused.

[ljharb]

Presumably if you const { notifications } = this.props instead, it passes?

[laumair]

Presumably if you const { notifications } = this.props instead, it passes?

Yep, it passes on destructuring props.

[ljharb]

Although I’d strongly recommend that pattern, yours should certainly work if possible.

[jzabala]

@ljharb the optimal solution would be to handle every possible edge case but things can get out of hand very quickly. Like:

• Passing the props as argument renderSomething(this.props)
• Or reassigning props more that one:

var props = this.props
var moreProps = {more: true, ...props}
// ... do something with moreProps

In the case presented by this issue what would be the added value of this:

customizeNotifications() {
    const props = this.props;
    return props.notifications.map((notification) => `foo${notification}`);
  }

vs

customizeNotifications() {
    return this.props.notifications.map((notification) => `foo${notification}`);
  }

[ljharb]

I don't think there's much added value - they should do const { notifications } = this.props; regardless :-) but it's nice when we can correctly analyze as much as possible.

I think eslint provides a number of utilities to make tracking the source of a variable easier?

[jzabala]

I don't think there's much added value - they should do const { notifications } = this.props; regardless :-) but it's nice when we can correctly analyze as much as possible.

Awesome.

I think eslint provides a number of utilities to make tracking the source of a variable easier?

Yeah, you can use context.getDeclaredVariables for that. In this case though is wasn't necessary since it seems it was fixed by another PR. I created a PR with a test for this issue.