-
Notifications
You must be signed in to change notification settings - Fork 76
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
New rule suggestion: no-access-state-in-setstate #172
Comments
In #80 it was suggested for this rule to have an option for only allowing the functional way of setting state instead of making this a standalone rule. this option could allow for quite a performance boost in detecting failing cases. |
Oh my, I already submitted a PR (#190) for this a while ago but somehow managed to link the wrong issue back then.. changed that now :) |
In case your wondering about the progress of this issue: I started working on the typed rule but ran into some problems and now need a bit of help, #190 (comment) :-) Feel free to share your knowledge ♥ |
This suggestion is still a good idea, but it should be migrated to an eslint rule. See #210 |
no need to migrate it, the idea came from an eslint rule, see description |
This is the same as https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-access-state-in-setstate.md
The purpose: to deny using
this.state
insidethis.setState
call.Why: Given
this.setState
mutates the state asynchronously it's extremely easy to introduce a subtle bug when in 2 sequential calls one relies on a particularthis.state
state. And if thosethis.setState
calls are in different functions and spatially not even close the problem might be really challenging to debug.The text was updated successfully, but these errors were encountered: