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

Include server component names in the componentStack in DEV #28415

Merged
merged 1 commit into from
Feb 23, 2024

Conversation

sebmarkbage
Copy link
Collaborator

@sebmarkbage sebmarkbage commented Feb 22, 2024

I'm a bit ambivalent about this one because it's not the main strategy that I plan on pursuing. I plan on replacing most DEV-only specific stacks like console.error stacks with a new take on owner stacks and native stacks. The future owner stacks may or may not be exposed to error boundaries in DEV but if they are they'd be a new errorInfo property since they're owner based and not available in prod.

The use case in console.error mostly goes away in the future so this PR is mainly for error boundaries. It doesn't hurt to have it in there while I'm working on the better stacks though.

The componentStack property exposed to error boundaries is more like production behavior similar to new Error().stack (which even in DEV won't ever expose owner stacks because console.createTask doesn't affect these). I'm not sure it's worth adding server components in DEV (this PR) because then you have forked behavior between dev and prod.

However, since even in the future there won't be any other place to get the parent stack, maybe this can be useful information even if it's only dev. We could expose a third property on errorInfo that's DEV only and parent stack but including server components. That doesn't seem worth it over just having the stack differ in dev and prod.

I don't plan on adding line/column number to these particular stacks.

A follow up could be to add this to Fizz prerender too but only in DEV.

@react-sizebot
Copy link

react-sizebot commented Feb 22, 2024

Comparing: 66c8346...fe343f8

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.min.js = 176.86 kB 176.86 kB = 55.14 kB 55.14 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js = 179.01 kB 179.01 kB = 55.78 kB 55.78 kB
facebook-www/ReactDOM-prod.classic.js = 592.40 kB 592.40 kB = 104.67 kB 104.67 kB
facebook-www/ReactDOM-prod.modern.js = 575.68 kB 575.68 kB = 101.66 kB 101.66 kB
test_utils/ReactAllWarnings.js Deleted 66.59 kB 0.00 kB Deleted 16.30 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 66.59 kB 0.00 kB Deleted 16.30 kB 0.00 kB

Generated by 🚫 dangerJS against fe343f8

@gnoff
Copy link
Collaborator

gnoff commented Feb 23, 2024

Should the server component frames indicate they are not from the local environment?

@@ -86,4 +86,41 @@ describe('component stack', () => {
'\n in Example (at **)',
);
});

// @reactVersion >=16.9
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// @reactVersion >=16.9

I think its fair to test this behaviour against react from main, not against react 17 or 18.

@sebmarkbage
Copy link
Collaborator Author

Should the server component frames indicate they are not from the local environment?

They have a (Server) suffix. It just doesn't show up because our stack normalization is very naive and strips out this (and adds at (**) where there would be no source line).

This is actually a little tricky in real life too though because for example error-stack-parser doesn't know how to parse these lines. However, that's already a problem with the built ins and host component frames. So using a regular off-the-shelf parser might not work - which was kind of the point that this should work. Maybe that's just inherent to naive parsers like that though and it's up to them to be a bit smarter.

I was considering using brackets instead but I'm not sure if that's used by any formats for other purposes. Where as (native) is a common pattern which this follows kind of.

@sebmarkbage sebmarkbage merged commit 8fb0233 into facebook:main Feb 23, 2024
37 checks passed
github-actions bot pushed a commit that referenced this pull request Feb 23, 2024
I'm a bit ambivalent about this one because it's not the main strategy
that I plan on pursuing. I plan on replacing most DEV-only specific
stacks like `console.error` stacks with a new take on owner stacks and
native stacks. The future owner stacks may or may not be exposed to
error boundaries in DEV but if they are they'd be a new errorInfo
property since they're owner based and not available in prod.

The use case in `console.error` mostly goes away in the future so this
PR is mainly for error boundaries. It doesn't hurt to have it in there
while I'm working on the better stacks though.

The `componentStack` property exposed to error boundaries is more like
production behavior similar to `new Error().stack` (which even in DEV
won't ever expose owner stacks because `console.createTask` doesn't
affect these). I'm not sure it's worth adding server components in DEV
(this PR) because then you have forked behavior between dev and prod.

However, since even in the future there won't be any other place to get
the *parent* stack, maybe this can be useful information even if it's
only dev. We could expose a third property on errorInfo that's DEV only
and parent stack but including server components. That doesn't seem
worth it over just having the stack differ in dev and prod.

I don't plan on adding line/column number to these particular stacks.

A follow up could be to add this to Fizz prerender too but only in DEV.

DiffTrain build for [8fb0233](8fb0233)
hoxyq added a commit that referenced this pull request Mar 5, 2024
* feat[devtools]: symbolicate source for inspected element
([hoxyq](https://github.com/hoxyq) in
[#28471](#28471))
* refactor[devtools]: lazily define source for fiber based on component
stacks ([hoxyq](https://github.com/hoxyq) in
[#28351](#28351))
* fix[devtools/tree/element]: onClick -> onMouseDown to handle first
click correctly ([hoxyq](https://github.com/hoxyq) in
[#28486](#28486))
* [DOM] disable legacy mode behind flag
([gnoff](https://github.com/gnoff) in
[#28468](#28468))
* Fix Broken Links In Documentation
([justindhillon](https://github.com/justindhillon) in
[#28321](#28321))
* Update /link URLs to react.dev
([rickhanlonii](https://github.com/rickhanlonii) in
[#28477](#28477))
* [tests] add support for @GATE pragma
([gnoff](https://github.com/gnoff) in
[#28479](#28479))
* Devtools: Unwrap Promise in useFormState
([eps1lon](https://github.com/eps1lon) in
[#28319](#28319))
* Add support for rendering BigInt
([eps1lon](https://github.com/eps1lon) in
[#24580](#24580))
* Include server component names in the componentStack in DEV
([sebmarkbage](https://github.com/sebmarkbage) in
[#28415](#28415))
EdisonVan pushed a commit to EdisonVan/react that referenced this pull request Apr 15, 2024
…#28415)

I'm a bit ambivalent about this one because it's not the main strategy
that I plan on pursuing. I plan on replacing most DEV-only specific
stacks like `console.error` stacks with a new take on owner stacks and
native stacks. The future owner stacks may or may not be exposed to
error boundaries in DEV but if they are they'd be a new errorInfo
property since they're owner based and not available in prod.

The use case in `console.error` mostly goes away in the future so this
PR is mainly for error boundaries. It doesn't hurt to have it in there
while I'm working on the better stacks though.

The `componentStack` property exposed to error boundaries is more like
production behavior similar to `new Error().stack` (which even in DEV
won't ever expose owner stacks because `console.createTask` doesn't
affect these). I'm not sure it's worth adding server components in DEV
(this PR) because then you have forked behavior between dev and prod.

However, since even in the future there won't be any other place to get
the *parent* stack, maybe this can be useful information even if it's
only dev. We could expose a third property on errorInfo that's DEV only
and parent stack but including server components. That doesn't seem
worth it over just having the stack differ in dev and prod.

I don't plan on adding line/column number to these particular stacks.

A follow up could be to add this to Fizz prerender too but only in DEV.
EdisonVan pushed a commit to EdisonVan/react that referenced this pull request Apr 15, 2024
* feat[devtools]: symbolicate source for inspected element
([hoxyq](https://github.com/hoxyq) in
[facebook#28471](facebook#28471))
* refactor[devtools]: lazily define source for fiber based on component
stacks ([hoxyq](https://github.com/hoxyq) in
[facebook#28351](facebook#28351))
* fix[devtools/tree/element]: onClick -> onMouseDown to handle first
click correctly ([hoxyq](https://github.com/hoxyq) in
[facebook#28486](facebook#28486))
* [DOM] disable legacy mode behind flag
([gnoff](https://github.com/gnoff) in
[facebook#28468](facebook#28468))
* Fix Broken Links In Documentation
([justindhillon](https://github.com/justindhillon) in
[facebook#28321](facebook#28321))
* Update /link URLs to react.dev
([rickhanlonii](https://github.com/rickhanlonii) in
[facebook#28477](facebook#28477))
* [tests] add support for @GATE pragma
([gnoff](https://github.com/gnoff) in
[facebook#28479](facebook#28479))
* Devtools: Unwrap Promise in useFormState
([eps1lon](https://github.com/eps1lon) in
[facebook#28319](facebook#28319))
* Add support for rendering BigInt
([eps1lon](https://github.com/eps1lon) in
[facebook#24580](facebook#24580))
* Include server component names in the componentStack in DEV
([sebmarkbage](https://github.com/sebmarkbage) in
[facebook#28415](facebook#28415))
bigfootjon pushed a commit that referenced this pull request Apr 18, 2024
I'm a bit ambivalent about this one because it's not the main strategy
that I plan on pursuing. I plan on replacing most DEV-only specific
stacks like `console.error` stacks with a new take on owner stacks and
native stacks. The future owner stacks may or may not be exposed to
error boundaries in DEV but if they are they'd be a new errorInfo
property since they're owner based and not available in prod.

The use case in `console.error` mostly goes away in the future so this
PR is mainly for error boundaries. It doesn't hurt to have it in there
while I'm working on the better stacks though.

The `componentStack` property exposed to error boundaries is more like
production behavior similar to `new Error().stack` (which even in DEV
won't ever expose owner stacks because `console.createTask` doesn't
affect these). I'm not sure it's worth adding server components in DEV
(this PR) because then you have forked behavior between dev and prod.

However, since even in the future there won't be any other place to get
the *parent* stack, maybe this can be useful information even if it's
only dev. We could expose a third property on errorInfo that's DEV only
and parent stack but including server components. That doesn't seem
worth it over just having the stack differ in dev and prod.

I don't plan on adding line/column number to these particular stacks.

A follow up could be to add this to Fizz prerender too but only in DEV.

DiffTrain build for commit 8fb0233.
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.

5 participants