[Fiber] Use Owner/JSX Stack When Appending Stacks to Console #29206
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
|
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 |
tjallingt
reviewed
May 22, 2024
tjallingt
reviewed
May 22, 2024
sebmarkbage
force-pushed
the
ownerstacks
branch
2 times, most recently
from
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', () => { | |||
| 1, | ||
| ], | ||
| ], | ||
| "errors": [], |
| // @gate !disableStringRefs | ||
| it('throws an error', async () => { | ||
| // @gate !disableStringRefs && !__DEV__ | ||
| it('throws an error in prod', async () => { |
There was a problem hiding this comment.
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.
hoxyq
approved these changes
May 23, 2024
Comment on lines
+94
to
+96
| if (!enableOwnerStacks || !__DEV__) { | ||
| return ''; | ||
| } |
There was a problem hiding this comment.
Are we going to fallback to getStackByFiberInDevAndProd in PROD?
There was a problem hiding this comment.
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.erroroverride 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.
github-actions bot
pushed a commit
that referenced
this pull request
May 25, 2024
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.
github-actions bot
pushed a commit
that referenced
this pull request
May 25, 2024
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)
sebmarkbage
added a commit
that referenced
this pull request
May 26, 2024
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.
github-actions bot
pushed a commit
that referenced
this pull request
May 26, 2024
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.
github-actions bot
pushed a commit
that referenced
this pull request
May 26, 2024
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)
sebmarkbage
added a commit
that referenced
this pull request
May 31, 2024
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.
github-actions bot
pushed a commit
that referenced
this pull request
May 31, 2024
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.
github-actions bot
pushed a commit
that referenced
this pull request
May 31, 2024
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one should be fully behind the
enableOwnerStacksflag.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.errorcalls 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
onCaughtErrorfor example or inside a customconsole.erroroverride.In another follow up I'll use
console.createTaskinstead and completely remove these stacks if it's available.