-
Notifications
You must be signed in to change notification settings - Fork 49.6k
[compiler] Option to treat "set-" prefixed callees as setState functions #34505
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
Conversation
Calling setState functions during render can lead to extraneous renders or even infinite loops. We also have runtime detection for loops, but static detection is obviously even better.
This PR adds an option to infer identifers as setState functions if both the following conditions are met:
- The identifier is named starting with "set"
- The identifier is used as the callee of a call expression
By inferring values as SetState type, this allows our existing ValidateNoSetStateInRender rule to flag calls during render, disallowing examples like the following:
```js
function Component({setParentState}) {
setParentState(...);
^^^^^^^^^^^^^^ Error: Cannot call setState in render
}
```
1d1693d to
9eccdf8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks for addressing this on short notice.
…ons (#34505) Calling setState functions during render can lead to extraneous renders or even infinite loops. We also have runtime detection for loops, but static detection is obviously even better. This PR adds an option to infer identifers as setState functions if both the following conditions are met: - The identifier is named starting with "set" - The identifier is used as the callee of a call expression By inferring values as SetState type, this allows our existing ValidateNoSetStateInRender rule to flag calls during render, disallowing examples like the following: ```js function Component({setParentState}) { setParentState(...); ^^^^^^^^^^^^^^ Error: Cannot call setState in render } ``` DiffTrain build for [7899729](7899729)
…ons (#34505) Calling setState functions during render can lead to extraneous renders or even infinite loops. We also have runtime detection for loops, but static detection is obviously even better. This PR adds an option to infer identifers as setState functions if both the following conditions are met: - The identifier is named starting with "set" - The identifier is used as the callee of a call expression By inferring values as SetState type, this allows our existing ValidateNoSetStateInRender rule to flag calls during render, disallowing examples like the following: ```js function Component({setParentState}) { setParentState(...); ^^^^^^^^^^^^^^ Error: Cannot call setState in render } ``` DiffTrain build for [7899729](7899729)
…ons (facebook#34505) Calling setState functions during render can lead to extraneous renders or even infinite loops. We also have runtime detection for loops, but static detection is obviously even better. This PR adds an option to infer identifers as setState functions if both the following conditions are met: - The identifier is named starting with "set" - The identifier is used as the callee of a call expression By inferring values as SetState type, this allows our existing ValidateNoSetStateInRender rule to flag calls during render, disallowing examples like the following: ```js function Component({setParentState}) { setParentState(...); ^^^^^^^^^^^^^^ Error: Cannot call setState in render } ``` DiffTrain build for [7899729](facebook@7899729)
…ons (facebook#34505) Calling setState functions during render can lead to extraneous renders or even infinite loops. We also have runtime detection for loops, but static detection is obviously even better. This PR adds an option to infer identifers as setState functions if both the following conditions are met: - The identifier is named starting with "set" - The identifier is used as the callee of a call expression By inferring values as SetState type, this allows our existing ValidateNoSetStateInRender rule to flag calls during render, disallowing examples like the following: ```js function Component({setParentState}) { setParentState(...); ^^^^^^^^^^^^^^ Error: Cannot call setState in render } ``` DiffTrain build for [7899729](facebook@7899729)
|
How about enforcing that a setState sent as a prop can only be sent in a prop named with the prefix |
|
@marchaase I thought about that too, but it is also generally reasonable to pass a setState function as a custom event handler, eg |
Calling setState functions during render can lead to extraneous renders or even infinite loops. We also have runtime detection for loops, but static detection is obviously even better.
This PR adds an option to infer identifers as setState functions if both the following conditions are met:
By inferring values as SetState type, this allows our existing ValidateNoSetStateInRender rule to flag calls during render, disallowing examples like the following: