feat[devtools]: symbolicate source for inspected element

[hoxyq]

Stacked on #28351, please review only the last commit.

Top-level description of the approach:

1. Once user selects an element from the tree, frontend asks backend to return the inspected element, this is where we simulate an error happening in render function of the component and then we parse the error stack. As an improvement, we should probably migrate from custom implementation of error stack parser to error-stack-parser from npm.
2. When frontend receives the inspected element and this object is being propagated, we create a Promise for symbolicated source, which is then passed down to all components, which are using source.
3. These components use use hook for this promise and are wrapped in Suspense.

Caching:

1. For browser extension, we cache Promises based on requested resource + key + column, also added use of chrome.devtools.inspectedWindow.getResource API.
2. For standalone case (RN), we cache based on requested resource url, we cache the content of it.

[react-sizebot]

Comparing: 61bd004...2a1097f

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	=	177.19 kB	177.19 kB	=	55.23 kB	55.23 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	177.72 kB	177.72 kB	=	55.55 kB	55.55 kB
facebook-www/ReactDOM-prod.classic.js	=	594.67 kB	594.67 kB	=	105.04 kB	105.04 kB
facebook-www/ReactDOM-prod.modern.js	=	577.93 kB	577.93 kB	=	102.10 kB	102.10 kB
test_utils/ReactAllWarnings.js	Deleted	66.60 kB	0.00 kB	Deleted	16.28 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.60 kB	0.00 kB	Deleted	16.28 kB	0.00 kB

Generated by 🚫 dangerJS against 2a1097f

[motiz88]

This all seems broadly reasonable. Added some thoughts. In general, making source map logic reliable is a matter of testing, testing and more testing, so I would encourage you to beef up the automated test coverage here as necessary.

[motiz88]

Is there some better way to normalise URLs (e.g. with a spec-compliant URL parser?) What does Chromium actually use for this normalisation?

[hoxyq]

There is https://www.npmjs.com/package/normalize-url, but it doesn't support custom protocols, like webpack or webpack-internal.

For now I think its just worth moving to a function -

react/packages/react-devtools-shared/src/utils.js

Lines 959 to 962 in eb9289f

	// This is a hacky one to just support this exact case.
	export function normalizeUrl(url: string): string {
	return url.replace('/./', '/');
	}

Don't really want RDT to support every possible bundler behaviour and perform this URL management. If we end up having such cases, which would require some support from us explicitly, then we can update the normalizeURL implementation.

[motiz88]

Should we subscribe to onResourceAdded and maintain a Map of resources instead of doing an O(n) find for every URL?

[hoxyq]

We can't because this event is emitted once resource is added: if main frame resources are loaded and user then opens browser DevTools, the listener won't be called with main frame resources.

If this gets slow for larger apps, I can work on some caching and normalization (to get resource in O(1)), probably

[motiz88]

Are there unit tests for this logic? Would love to see the concrete cases affected by this.

[hoxyq]

Thanks for flagging, I will move it to #28351 and add unit tests

[motiz88]

What would it take to use https://www.npmjs.com/package/jsc-safe-url here?

[hoxyq]

Didn't know we have this, will use it, thanks