When we use a prop only with nextProps to set the state in the componentWillRecieveProps(nextProps) method and not elsewhere we get react/no-used-prop-types error for the prop in the propTypes block.
Same as #801
Here is an excerpt of my code:
class MyComponent extends React.Component {
static propTypes = {
isLoading: React.PropTypes.bool, // eslint-disable-line react/no-unused-prop-types
error: React.PropTypes.bool, // eslint-disable-line react/no-unused-prop-types
}
static defaultProps = {
isLoading: true,
error: false,
};
constructor(props) {
super(props);
this.state = {
isLoading: true,
error: false,
};
}
componentWillReceiveProps(props) {
if (props.error) {
this.setState({ ...this.state, error: props.error });
} else {
this.setState({
...this.state,
isLoading: props.isLoading,
error: false,
});
}
}
// the rest of the code
}
Notice I have to use // eslint-disable-line react/no-unused-prop-types to avoid the warnings
@mjilugu & @ljharb -
Just as an FYI, I found that if you destructure nextProps, the linter does not throw an error in this scenario. If you use dot notation, it fails.
I also confirmed others have seen similar results in this thread: #884 (comment)
Please can you fix this - having the same issue :(
I could try and take a look at this. Not sure how far I will get.
I see that the same issue exists with shouldComponentUpdate and nextProps: https://github.com/yannickcr/eslint-plugin-react/issues/1213
Hi,
This issue seems fixed in https://github.com/yannickcr/eslint-plugin-react/pull/1106 - E.g. it should work on the 7.0.0 release (which was released after this issue was created.). @joetidee can you please let me know what version you use and what is failing for you?
Just to be clear, the example code from the original issue works. See below for a more concise example:
The following example passes eslint-plugin-react test cases so it should work
class Hello extends Component {
static propTypes = {
foo: PropTypes.string
bar: PropTypes.string
};
componentWillReceiveProps (nextProps) {
if (nextProps.foo) {
return true;
}
}
render() {
return (<div>{this.props.bar}</div>);
}
}
The following example does NOT pass eslint-plugin-react test cases so it should NOT work
class Hello extends Component {
static propTypes = {
foo: PropTypes.string
bar: PropTypes.string
};
shouldComponentUpdate (nextProps) { // replace componentWIllReceiveProps with shouldComponentUpdate
if (nextProps.foo) {
return true;
}
}
render() {
return (<div>{this.props.bar}</div>);
}
}
I identified a few issues:
props or nextProps. Calling it foo will not work. (not sure if there is a rule for that)nextProps for componentWillReceiveProps, but not for other React lifecycle methods (e.g. shouldComponentUpdate(nextProps) and componentDidUpdate(nextProps)componentDidUpdate(prevProps) due to a combination of both points above.I'll get one or a few PR-s out for this within the next few days. As I believe we might as well fix all three points but it may be better to handle them one issue at a time. :)
Excellent - thanks - have upgraded to 7.0.0 and now fixed.
@mqklin could you file a new issue about that?
@ljharb there is already: https://github.com/yannickcr/eslint-plugin-react/issues/814
still not working here
I have componentWillReceiveProps but I don't use the prop there, I pass nextProps to a function call inside the lifecycle method and then in there I go ahead and access the prop via dot notation or object destruction, but next to the prop declaration inside PropsType(using flow) I see 'helperAppStatus' PropType is defined but prop is never used eslint(react/no-unused-prop-types)
using 7.12.4
@pkhodaveissi if you pass a props or state object around, you’ve both defeated all static analysis and also, you’ve given up control of a mutable object that your component depends on, a bad practice.
Always extract every prop/state from the objects immediately, and pass those around.
Thank you for your helpful feedback
On Sat, May 25, 2019 at 7:34 PM Jordan Harband notifications@github.com
wrote:
@pkhodaveissi https://github.com/pkhodaveissi if you pass a props or
state object around, you’ve both defeated all static analysis and also,
you’ve given up control of a mutable object that your component depends on,
a bad practice.Always extract every prop/state from the objects immediately, and pass
those around.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yannickcr/eslint-plugin-react/issues/1142?email_source=notifications&email_token=AA72IKYYZ56EOUG7VN7HXSTPXFIQLA5CNFSM4DG3ITZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHTOYQ#issuecomment-495925090,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA72IK2ZU264B35HFZOTWS3PXFIQLANCNFSM4DG3ITZA
.
Most helpful comment
Hi,
This issue seems fixed in https://github.com/yannickcr/eslint-plugin-react/pull/1106 - E.g. it should work on the 7.0.0 release (which was released after this issue was created.). @joetidee can you please let me know what version you use and what is failing for you?
Just to be clear, the example code from the original issue works. See below for a more concise example:
The following example passes eslint-plugin-react test cases so it should work
The following example does NOT pass eslint-plugin-react test cases so it should NOT work
I identified a few issues:
propsornextProps. Calling itfoowill not work. (not sure if there is a rule for that)nextPropsforcomponentWillReceiveProps, but not for other React lifecycle methods (e.g.shouldComponentUpdate(nextProps)andcomponentDidUpdate(nextProps)componentDidUpdate(prevProps)due to a combination of both points above.I'll get one or a few PR-s out for this within the next few days. As I believe we might as well fix all three points but it may be better to handle them one issue at a time. :)