[compiler] Extend setState in effect validation to useEffectEvent

[jackpope]

ValidateNoSetStateInEffects already supports transitive setter functions. This PR marks any synchonous state setter useEffectEvent function so we can validate that uEE isn't being used only as misdirection to avoid the validation within an effect body.

The error points to the call of the effect event.

Example:

export default function MyApp() {
  const [count, setCount] = useState(0)
  const effectEvent = useEffectEvent(() => {
    setCount(10)
  })
  useEffect(() => {
    effectEvent()
  }, [])
  return <div>{count}</div>;

Found 1 error:

Error: Calling setState synchronously within an effect can trigger cascading renders

Effects are intended to synchronize state between React and external systems such as manually updating the DOM, state management libraries, or other platform APIs. In general, the body of an effect should do one or both of the following:
* Update external systems with the latest state from React.
* Subscribe for updates from some external system, calling setState in a callback function when external state changes.

Calling setState synchronously within an effect body causes cascading renders that can hurt performance, and is not recommended. (https://react.dev/learn/you-might-not-need-an-effect).

   5 |   })
   6 |   useEffect(() => {
>  7 |     effectEvent()
     |     ^^^^^^^^^^^ Avoid calling setState() directly within an effect
   8 |   }, [])
   9 |   return <div>{count}</div>;
  10 | }

[jorge-cab]

This would only catch useEffectEvent function type calls at the top level in a useEffect right? Should we consider something like this?

const [state, setState] = useState(0)
const effectEvent = useEffectEvent(() => {
        setState(true)
    });

useEffect(() => {
    function foo() {
        effectEvent()
    }
    
    someLogic();
    foo();
}, [])

I'm just curious. Would this code even work? I'm not very familiar with uEE

[josephsavona]

I don't think there's anything to specific about uEE in that example: it's just a question of whether we check recursive function expression (looks like maybe not, would be an easy extension). But that's an orthogonal change.

[josephsavona]

I double-checked, we don't currently catch this case if you swap the effectEvent() call for a direct setState() call. Definitely worth adding — great catch, @jorge-cab! — but not strictly related to this PR

[josephsavona]

can do else if to connect w the existing condition, since they can't both be true

[gaearon]

I actually bumped into this one today and I'm not sure what the intended solution for "did mount" flag is. Specifically, if you need to use some browser-only stuff in JSX, so you're forced to separate hydration in two stages (initial server content -> client content). See https://react.dev/reference/react/useEffect#displaying-different-content-on-the-server-and-the-client for this use case described in the docs.