KEMBAR78
[compiler] Option to treat "set-" prefixed callees as setState functions by josephsavona · Pull Request #34505 · facebook/react · GitHub
Skip to content

Conversation

@josephsavona
Copy link
Member

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:

function Component({setParentState}) {
  setParentState(...);
  ^^^^^^^^^^^^^^ Error: Cannot call setState in render
}

@meta-cla meta-cla bot added the CLA Signed label Sep 16, 2025
@github-actions github-actions bot added the React Core Team Opened by a member of the React Core Team label Sep 16, 2025
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
}
```
Copy link

@sudojorian sudojorian left a 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.

@josephsavona josephsavona merged commit 7899729 into main Sep 16, 2025
21 checks passed
github-actions bot pushed a commit that referenced this pull request Sep 16, 2025
…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)
github-actions bot pushed a commit that referenced this pull request Sep 16, 2025
…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)
github-actions bot pushed a commit to code/lib-react that referenced this pull request Sep 21, 2025
…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)
github-actions bot pushed a commit to code/lib-react that referenced this pull request Sep 21, 2025
…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)
@marchaase
Copy link

How about enforcing that a setState sent as a prop can only be sent in a prop named with the prefix set?

@josephsavona
Copy link
Member Author

@marchaase I thought about that too, but it is also generally reasonable to pass a setState function as a custom event handler, eg <CustomInput onChange={setState} />. The inference here doesn't cover all cases (may have false negatives) but should be a good compromise and high signal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed React Core Team Opened by a member of the React Core Team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants