facebook
[Fiber] Enable Native console.createTask Stacks When Available
Stacked on #29206 and #29221.
This disables appending owner stacks to console when console.createTask is available in the environment. Instead we rely on native "async" stacks that end up looking like this with source maps and ignore list enabled.
Unfortunately Chrome requires a string name for each async stack and, worse, a suffix of (async) is automatically added which is very confusing since it seems like it might be an async component or something which it is not.
In this case it's not so bad because it's nice to refer to the host component which otherwise doesn't have a stack frame since it's internal. However, if there were more owners here there would also be a <Counter> (async) which ends up being kind of duplicative.
If the Chrome DevTools is not open from the start of the app, then console.createTask is disabled and so you lose the stack for those errors (or those parents if the devtools is opened later). Unlike our appended ones that are always added. That's unfortunate and likely to be a bit of a DX issue but it's also nice that it saves on perf in DEV mode for those cases. Framework dialogs can still surface the stack since we also track it in user space in parallel.
This currently doesn't track Server Components yet. We need a more clever hack for that part in a follow up.
I think I probably need to also add something to React DevTools to disable its stacks for this case too. Since it looks for stacks in the console.error and adds a stack otherwise. Since we don't add them anymore from the runtime, the DevTools adds them instead.
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 | May 26, 2024 9:42pm |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
Comparing: b078c810c787cf13d9bd1958f083b4e3a162a720...5adda9c56fcfe8fa3a7b3f9be9833709acde16c5
Critical size changes
Includes critical production bundles, as well as any change greater than 2%:
Significant size changes
Includes any change greater than 0.2%:
Expand to show
Generated by :no_entry_sign: dangerJS against 5adda9c56fcfe8fa3a7b3f9be9833709acde16c5
We (the Chrome DevTools team) are looking into ways for pages to enable async stack traces without opening DevTools. Possible avenues are 1) dedicated (new) API on the console object, 2) HTTP header, 3) meta tag.
Any preference from the react side how to enable async stacks or other ideas how to opt-in?
Notes from the meeting between Chrome DevTools and React folks, following up on the questions from @szuend.
There are two separate use cases here:
- To keep the async stack traces when DevTools is not open in the beginning, but the user opens DevTools later. Then ideally the page would have the async stack traces. This could use an HTTP header, some API or a meta tag. Anything would work (according to @sebmarkbage).
- The bundler or other parts of the toolchain (or some in-page DevTools) put up a fullscreen error message with a stack trace. For example, webpack offers this. Ideally that would also show the async stack traces.
For 2. (DevTools) extensions (like React DevTools) would preferably have access to source maps. Because stack traces not only need to be manually stitched together with async stack traces, but these tools also need to replicate the logic for source maps.
Extending Error.stack is probably not a good idea according to @sebmarkbage, because this would differ in other places from production behavior. Ideally have some other means of extracting the full (sync + async) stack trace from the Error object as structured data and cross-browser! If however it's easier to spec cross-browser with a string, then a string does that.
reportError also seems to be weird, in that it has the sync stack trace from the error passed to it, but the async stack trace from its call site.
