-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
[Fiber] Use Owner/JSX Stack When Appending Stacks to Console #29206
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Comparing: 84239da...65d16bb Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show |
a2086cd
to
67c9f7d
Compare
@@ -1386,19 +1389,40 @@ describe('ReactFlight', () => { | |||
ReactNoopFlightClient.read(transport); | |||
}); | |||
|
|||
it('should warn in DEV a child is missing keys', () => { | |||
it('should warn in DEV a child is missing keys on server component', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
1, | ||
], | ||
], | ||
"errors": [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wat
// @gate !disableStringRefs | ||
it('throws an error', async () => { | ||
// @gate !disableStringRefs && !__DEV__ | ||
it('throws an error in prod', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How was this passing before?
Currently this is just keeps the original stack/task and doesn't update with new elements, which is the same as _debugOwner but it could be changed to update.
Skip the React internals for the stack outside user space.
This ensures that the name is used by real stack traces.
They provide more context than the owner stacks since it's about parent nesting. We should really just use a diff view here that can highlight the affected parent/child nodes in the diff view.
…nDev To do this we need to break out the jsxDEV implementation into a helper.
if (!enableOwnerStacks || !__DEV__) { | ||
return ''; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to fallback to getStackByFiberInDevAndProd
in PROD?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we could really error here because this should not be called in prod. Hence InDev
suffix.
That's because we never add component stacks to prod automatically:
- We only include our own
console.error
override in DEV. - We only include our component stacks for default onCaughtError/onUncaughtError in DEV.
- When we eventually expose this to the errorInfo object it would be on a DEV-only property.
The React DevTools could in principle be different. Basically older React versions will look the same as prod versions of new React.
This one should be fully behind the `enableOwnerStacks` flag. Instead of printing the parent Component stack all the way to the root, this now prints the owner stack of every JSX callsite. It also includes intermediate callsites between the Component and the JSX call so it has potentially more frames. Mainly it provides the line number of the JSX callsite. In terms of the number of components is a subset of the parent component stack so it's less information in that regard. This is usually better since it's more focused on components that might affect the output but if it's contextual based on rendering it's still good to have parent stack. Therefore, I still use the parent stack when printing DOM nesting warnings but I plan on switching that format to a diff view format instead (Next.js already reformats the parent stack like this). __Follow ups__ - Server Components show up in the owner stack for client logs but logs done by Server Components don't yet get their owner stack printed as they're replayed. They're also not yet printed in the server logs of the RSC server. - Server Component stack frames are formatted as the server and added to the end but this might be a different format than the browser. E.g. if server is running V8 and browser is running JSC or vice versa. Ideally we can reformat them in terms of the client formatting. - This doesn't yet update Fizz or DevTools. Those will be follow ups. Fizz still prints parent stacks in the server side logs. The stacks added to user space `console.error` calls by DevTools still get the parent stacks instead. - It also doesn't yet expose these to user space so there's no way to get them inside `onCaughtError` for example or inside a custom `console.error` override. - In another follow up I'll use `console.createTask` instead and completely remove these stacks if it's available. DiffTrain build for commit d6cfa0f.
This one should be fully behind the `enableOwnerStacks` flag. Instead of printing the parent Component stack all the way to the root, this now prints the owner stack of every JSX callsite. It also includes intermediate callsites between the Component and the JSX call so it has potentially more frames. Mainly it provides the line number of the JSX callsite. In terms of the number of components is a subset of the parent component stack so it's less information in that regard. This is usually better since it's more focused on components that might affect the output but if it's contextual based on rendering it's still good to have parent stack. Therefore, I still use the parent stack when printing DOM nesting warnings but I plan on switching that format to a diff view format instead (Next.js already reformats the parent stack like this). __Follow ups__ - Server Components show up in the owner stack for client logs but logs done by Server Components don't yet get their owner stack printed as they're replayed. They're also not yet printed in the server logs of the RSC server. - Server Component stack frames are formatted as the server and added to the end but this might be a different format than the browser. E.g. if server is running V8 and browser is running JSC or vice versa. Ideally we can reformat them in terms of the client formatting. - This doesn't yet update Fizz or DevTools. Those will be follow ups. Fizz still prints parent stacks in the server side logs. The stacks added to user space `console.error` calls by DevTools still get the parent stacks instead. - It also doesn't yet expose these to user space so there's no way to get them inside `onCaughtError` for example or inside a custom `console.error` override. - In another follow up I'll use `console.createTask` instead and completely remove these stacks if it's available. DiffTrain build for [d6cfa0f](d6cfa0f)
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. <img width="673" alt="Screenshot 2024-05-22 at 4 00 27 PM" src="https://github.com/facebook/react/assets/63648/5313ed53-b298-4386-8f76-8eb85bdfbbc7"> 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.
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. <img width="673" alt="Screenshot 2024-05-22 at 4 00 27 PM" src="https://github.com/facebook/react/assets/63648/5313ed53-b298-4386-8f76-8eb85bdfbbc7"> 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. DiffTrain build for commit ea6e059.
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. <img width="673" alt="Screenshot 2024-05-22 at 4 00 27 PM" src="https://github.com/facebook/react/assets/63648/5313ed53-b298-4386-8f76-8eb85bdfbbc7"> 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. DiffTrain build for [ea6e059](ea6e059)
When defining a displayName on forwardRef/memo we forward that name to the inner function. We used to use displayName for this but in #29206 I switched this to use `"name"`. That's because V8 doesn't use displayName, it only uses the overridden name in stack traces. This is the only thing covered by our tests for component stacks. However, I realized that Safari only uses displayName and not the name. So this sets both.
When defining a displayName on forwardRef/memo we forward that name to the inner function. We used to use displayName for this but in #29206 I switched this to use `"name"`. That's because V8 doesn't use displayName, it only uses the overridden name in stack traces. This is the only thing covered by our tests for component stacks. However, I realized that Safari only uses displayName and not the name. So this sets both. DiffTrain build for commit 63d673c.
When defining a displayName on forwardRef/memo we forward that name to the inner function. We used to use displayName for this but in #29206 I switched this to use `"name"`. That's because V8 doesn't use displayName, it only uses the overridden name in stack traces. This is the only thing covered by our tests for component stacks. However, I realized that Safari only uses displayName and not the name. So this sets both. DiffTrain build for [63d673c](63d673c)
This one should be fully behind the
enableOwnerStacks
flag.Instead of printing the parent Component stack all the way to the root, this now prints the owner stack of every JSX callsite. It also includes intermediate callsites between the Component and the JSX call so it has potentially more frames. Mainly it provides the line number of the JSX callsite. In terms of the number of components is a subset of the parent component stack so it's less information in that regard. This is usually better since it's more focused on components that might affect the output but if it's contextual based on rendering it's still good to have parent stack. Therefore, I still use the parent stack when printing DOM nesting warnings but I plan on switching that format to a diff view format instead (Next.js already reformats the parent stack like this).
Follow ups
Server Components show up in the owner stack for client logs but logs done by Server Components don't yet get their owner stack printed as they're replayed. They're also not yet printed in the server logs of the RSC server.
Server Component stack frames are formatted as the server and added to the end but this might be a different format than the browser. E.g. if server is running V8 and browser is running JSC or vice versa. Ideally we can reformat them in terms of the client formatting.
This doesn't yet update Fizz or DevTools. Those will be follow ups. Fizz still prints parent stacks in the server side logs. The stacks added to user space
console.error
calls by DevTools still get the parent stacks instead.It also doesn't yet expose these to user space so there's no way to get them inside
onCaughtError
for example or inside a customconsole.error
override.In another follow up I'll use
console.createTask
instead and completely remove these stacks if it's available.