[Mistake]: set-state-in-effect gives a wrong example of bad usage

[zjlovezj]

Summary

react.dev/src/content/reference/eslint-plugin-react-hooks/lints/set-state-in-render.md

Lines 70 to 91 in abe931a

	### I want to sync state to a prop {/*clamp-state-to-prop*/}
	A common problem is trying to "fix" state after it renders. Suppose you want to keep a counter from exceeding a `max` prop:
	```js
	// ❌ Wrong: clamps during render
	function Counter({max}) {
	const [count, setCount] = useState(0);
	if (count > max) {
	setCount(max);
	}
	return (
	<button onClick={() => setCount(count + 1)}>
	{count}
	</button>
	);
	}
	```
	As soon as `count` exceeds `max`, an infinite loop is triggered.

Page

https://react.dev/reference/eslint-plugin-react-hooks/lints/set-state-in-render

Details

I want to sync state to a prop {/clamp-state-to-prop/}

A common problem is trying to "fix" state after it renders. Suppose you want to keep a counter from exceeding a max prop:

// ❌ Wrong: clamps during render
function Counter({max}) {
  const [count, setCount] = useState(0);

  if (count > max) {
    setCount(max);
  }

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

As soon as count exceeds max, an infinite loop is triggered.

I think this Counter component can be rendered and clicked without issues.
The claim that an infinite loop will be triggered is incorrect.

[justismailmemon]

Thanks for reporting this. I opened a PR to clarify the wording: #8413

[Assamee]

Hi! I’ve opened PR #8412 to address this.

I verified the behaviour locally: while it doesn't cause a literal infinite loop (the condition eventually becomes false), it interrupts the current render and forces React to start over, which impacts performance. I've updated the wording to clarify this behaviour rather than focusing on the infinite loop claim.