Skip to content
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

Execute event handlers in the context of the instance that it's associated with #29876

Merged
merged 1 commit into from
Jun 12, 2024

Conversation

sebmarkbage
Copy link
Collaborator

@sebmarkbage sebmarkbage commented Jun 12, 2024

That way we get owner stacks (native or otherwise) for console.error or console.warn inside of them.

Since the reportError is also called within this context, we also get them for errors thrown within event listeners. You'll also be able to observe this in in the error event. Similar to how onUncaughtError is in the scope of the instance that errored - even though onUncaughtError doesn't kick in for event listeners.

Chrome (from console.createTask):

Screenshot 2024-06-12 at 2 08 19 PM Screenshot 2024-06-12 at 2 03 32 PM

Firefox (from React DevTools):

Screenshot 2024-06-12 at 2 05 01 PM

(This is the parent stack since React DevTools doesn't just yet print owner stack.)

(Firefox doesn't print the component stack for uncaught since we don't add component stacks for "error" events from React DevTools - just console.error. Perhaps an oversight.)

If we didn't have the synthetic event system this would kind of just work natively in Chrome because we have this task active when we attach the event listeners to the DOM node and async stacks just follow along that way. In fact, if you attach a manual listener in useEffect you get this same effect. It's just because we use event delegation that this doesn't work.

However, if we did get rid of the synthetic event system we'd likely still want to add a wrapper on the DOM node to set our internal current owner so that the non-native part of the system still can observe the active instance. That wouldn't work with manually attached listeners though.

…iated with

That way we get owner stacks (native or other wise) for console.errors inside of them.

Since the reportError is also called within this context, we also get them
for errors thrown within these. Similar to how onUncaughtError is in the scope of the
instance that errored.
Copy link

vercel bot commented Jun 12, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
react-compiler-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 12, 2024 6:15pm

@react-sizebot
Copy link

Comparing: f3e09d6...1422b2d

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.js = 6.66 kB 6.66 kB = 1.82 kB 1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js = 497.80 kB 497.80 kB = 89.24 kB 89.24 kB
oss-experimental/react-dom/cjs/react-dom.production.js = 6.67 kB 6.67 kB = 1.83 kB 1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js = 502.62 kB 502.62 kB = 89.94 kB 89.94 kB
facebook-www/ReactDOM-prod.classic.js = 597.04 kB 597.04 kB = 105.31 kB 105.31 kB
facebook-www/ReactDOM-prod.modern.js = 571.38 kB 571.38 kB = 101.25 kB 101.25 kB
test_utils/ReactAllWarnings.js Deleted 63.50 kB 0.00 kB Deleted 15.90 kB 0.00 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show
Name +/- Base Current +/- gzip Base gzip Current gzip
test_utils/ReactAllWarnings.js Deleted 63.50 kB 0.00 kB Deleted 15.90 kB 0.00 kB

Generated by 🚫 dangerJS against 1422b2d

@sebmarkbage sebmarkbage merged commit 195d5bb into facebook:main Jun 12, 2024
43 of 44 checks passed
github-actions bot pushed a commit that referenced this pull request Jun 12, 2024
…iated with (#29876)

That way we get owner stacks (native or otherwise) for `console.error`
or `console.warn` inside of them.

Since the `reportError` is also called within this context, we also get
them for errors thrown within event listeners. You'll also be able to
observe this in in the `error` event. Similar to how `onUncaughtError`
is in the scope of the instance that errored - even though
`onUncaughtError` doesn't kick in for event listeners.

Chrome (from console.createTask):

<img width="306" alt="Screenshot 2024-06-12 at 2 08 19 PM"
src="https://github.com/facebook/react/assets/63648/34cd9d57-0df4-44df-a470-e89a5dd1b07d">

<img width="302" alt="Screenshot 2024-06-12 at 2 03 32 PM"
src="https://github.com/facebook/react/assets/63648/678117b1-e03a-47d4-9989-8350212c8135">

Firefox (from React DevTools):

<img width="493" alt="Screenshot 2024-06-12 at 2 05 01 PM"
src="https://github.com/facebook/react/assets/63648/94ca224d-354a-4ec8-a886-5740bcb418e5">

(This is the parent stack since React DevTools doesn't just yet print
owner stack.)

(Firefox doesn't print the component stack for uncaught since we don't
add component stacks for "error" events from React DevTools - just
console.error. Perhaps an oversight.)

If we didn't have the synthetic event system this would kind of just
work natively in Chrome because we have this task active when we attach
the event listeners to the DOM node and async stacks just follow along
that way. In fact, if you attach a manual listener in useEffect you get
this same effect. It's just because we use event delegation that this
doesn't work.

However, if we did get rid of the synthetic event system we'd likely
still want to add a wrapper on the DOM node to set our internal current
owner so that the non-native part of the system still can observe the
active instance. That wouldn't work with manually attached listeners
though.

DiffTrain build for commit 195d5bb.
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.

4 participants