useEffectEvent revamp #8279
useEffectEvent revamp #8279
Conversation
Size changesDetails📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
|
I do not know if it is this page or the You Might Not Need an Effect page, but there should be somewhere that explains where you would and would not use useEffectEvent more explicitly. |
|
Here’s the original doc that spells out the motivation more clearly: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event I agree that this reference page should ideally convey this (but shorter). Reading it now as it is, I don’t have a clear sense of what problem it solves. I do get this sense from the original doc so the challenge is how to compress it. |
| } | ||
| ``` | ||
|
|
||
| Effect Events are functions you can call inside Effects, such as `useEffect`. |
There was a problem hiding this comment.
i can call any functions inside Effects so this is neither correct nor useful. in particular, this makes it seem like you’re supposed to extract any callable functions into Effect Events, which is not what we want to say at all.
what i think we want to give here is conceptual grounding. it’s a way to for effect to notify the rest of the program that something happened — like an event handler. and it avoids that event handler’s content influencing how often the effect fires.
There was a problem hiding this comment.
Updated to:
Effect Events are a part of your Effect logic, but they behave more like an event handler. They always “see” the latest values of your props and state without re-synchronizing your Effect, so they're excluded from Effect dependencies. See Separating Events from Effects to learn more.
|
|
||
| The non-stable identity acts as a runtime assertion: if your code incorrectly depends on the function identity, you'll see the Effect re-running on every render, making the bug obvious. | ||
|
|
||
| This design reinforces the rule that Effect Events are "escape hatches" for reading the latest values, not general purpose callbacks to be passed around. |
There was a problem hiding this comment.
i wouldn’t say they’re escape hatches in this context (refs are). it’s more that conceptually their code belongs to a particular effect and you want to always be able to see both parts next to each other.
There was a problem hiding this comment.
Updated:
This design reinforces that Effect Events conceptually belong to a particular effect, and are not a general purpose API to opt-out of reactivity.
3 participants
Preview
Used the new claude skills to revamp the useEffectEvent docs, then did a human pass.
If you're interested, the first commit is claude's attempt, and the second commit is my edits.
Here's the PR with the claude improvements this used: #8280