Repository navigation
Distribute source maps for easier debugging in Chrome's Performance tab #20186
Description
I want to propose the addition of a new file in the react-dom npm package called react-dom.production.js — a non-minified version of react-dom production build.
Edit: After some discussion(see below) it seems that distributing source maps makes more sense. Source maps will help you see the real function names and explore them. (The points below apply for source maps as well.)
Why?
There are a few ways to profile React's performance — none of them provide a low-level view of what's happening. I believe the best way to profile React is using Chrome's Performance tab using a non-minified production build. Here's why:
- Familiar. People use the Performance tab for every other performance profiling so they are familiar with how to use it.
- Powerful. The Performance tab is extremely powerful. Years of engineering have been put into developing it.
- Better understanding. When using the React DevTools profiler I have a common problem – I see a component being rendered slowly but I don't know what is causing it. In order to understand I need a more low-level view. Here are some questions that can be answered only with the Chrome Performance tab:
- What's the balance between the app's code and React execution times? Should I implement some frequently updated components using custom non-React implementation?
- What time is spend on setting attribute values, setting
innerHTMLand adding and removing listeners? - What time is spent on disposing effects? Is there a specific dispose function that is taking more than usual?
- What time is spent on mounting effects? Is there a specific effect mount that is taking more than usual?
Disadvantages
As with every solution, there are some drawbacks to using this approach:
- Documentation needed. In order to make sense of what's happening you will need some knowledge of the core functions in React. A little guide with the names of the functions for mount/unmount, effects, and DOM manipulations will be useful. This of course can be done by the community(you are already linking to some community posts in React's documentation).
- Requires more skill. This isn't for everybody. It's aimed at more experienced developers. This type of profiling is a lot more overwhelming than the current approach.
- May not fit your principles. Maybe it's not part of your principles to introduce and promote such a complicated solution. Maybe you are more interested in searching for a more elegant and minimal solution.
Activity
bvaughn commentedon Nov 7, 2020
I don't understand this issue. Why does a minified build prevent you from using the browser's profiling tools?
astoilkov commentedon Nov 7, 2020
You can use the profiling tools but it is hard to reason about what's happening because of the minified function names. I will give some examples of when it is useful to have the real names:
flushPassiveEffectsImpl()taking a lot of time I know I should look at some of the dispose methods of effectssetValueForProperty()then I can think of lowering the number of attributes I am changingupdateDOMProperties()then I can change/remove thedangerouslySetInnerHTMLI can also answer the question "what time is used by React" which may let me use a custom implementation in performance-critical sections.
I can also click on every function I don't know about and explore the code and comments there and makes sense of what is happening.
[-]Support for profiling React production with Chrome's Performance tab[/-][+]Distribute non-minified React production build for easier debugging in Chrome's Performance tab[/+]astoilkov commentedon Nov 7, 2020
I think I understood why you were confused. From what I wrote it seems like it isn't possible to profile the production build. I changed the title to reflect that. My proposal is for improving the experience when profiling production.
bvaughn commentedon Nov 7, 2020
The React Profiler API, the DevTools extension profiler, and our experimental scheduling profiler are meant to give insight into the types of things you mention. Given the complexity of the internal React implementation, the profiling tools we maintain are probably going to provide better insight than manually inspecting React the way you describe. (That kind of manual inspection is often difficult even for those of us who work in React core daily.)
I wonder if providing source maps would help address the problem you mention of occasionally needing to step through React internals?
[-]Distribute non-minified React production build for easier debugging in Chrome's Performance tab[/-][+]Distribute source-maps for easier debugging in Chrome's Performance tab[/+]astoilkov commentedon Nov 7, 2020
I should have thought about source maps. I think this is the ideal solution. It's way better than my proposal.
Is there a way that the Profiler API and the DevTools extension shows the time spend on user code and React code separately? Also is there a way to see which part of the React code is taking the longest?
I will experiment with the scheduling profiler. This is the first time I've heard about it.
[-]Distribute source-maps for easier debugging in Chrome's Performance tab[/-][+]Distribute source maps for easier debugging in Chrome's Performance tab[/+]bvaughn commentedon Nov 7, 2020
No. These tools show the time spent in user code. This is because (a) a lot of energy has already been put into making React as fast as we can (given constraints) and (b) it's more feasible for people to performance-tune their own components and not React anyway.
astoilkov commentedon Nov 7, 2020
Thanks, makes sense.
What do you think about the source maps idea? Are you open to discussing and implementing it?
bvaughn commentedon Nov 7, 2020
Discussing it seems fine!
astoilkov commentedon Nov 7, 2020
Adding an issue I found on the topic: Question: Building react with sourcemaps.
0xdevalias commentedon Jul 10, 2021
This would definitely be useful for me. I actually just went looking to see if I could find sourcemaps for React (specifically we're using the minified production profiling versions of
react,react-dom, etc.My main use case is 'occasionally digging through things while profiling', but it would also provide better context if/when errors happen deep in React's code and are reported to Bugsnag/etc. As currently the stack traces tend to be a whole lot of minified/mangled names.
I would definitely want this to be as separate
.mapfiles rather than inlined though, as a majority of the time we wouldn't want/need the browser to be loading them.It looks like the places referenced in #14361 for enabling sourcemaps are:
Curious, is this the only place that would need to be changed for this? If not, what would be the canonical way for enabling this (even if only to build my own versions)?
jasonwilliams commentedon Jul 15, 2021
I got this working somewhat, I updated Rollup and all of the plugins, set sourcemaps to true and
SourceMaps: truein the babel config. Then worked through the plugins. Mainly by commenting them out then trying to build and adding them back in.Some I had to comment out though as i don't know how to add mapping support to some of these internal plugins I think
closureandstrip-unused-importscan be replaced by the terser plugin. Sizes could be replaced by https://www.npmjs.com/package/rollup-plugin-sizesI've had to give up for now though, if anyone else was looking into it that's what i've done
10 remaining items
0xdevalias commentedon Jul 10, 2022
@jasonwilliams Thanks for your work on that PR! It's taken me forever to get back to this, but I spent some time today going through it, leaving some rather in depth context/comments/etc, as well as researching solutions to what I believe should be the rest of the remaining issues.:
Would be awesome if we were able to get this feature finished up and merged in!
bvaughn commentedon Jan 10, 2023
Finding myself wanting this again this morning, trying to debug
invariant=321.https://twitter.com/brian_d_vaughn/status/1612806202559459330
Update Rollup and related plugins to their most recent versions (#24916)
Update Rollup and related plugins to their most recent versions (#24916)
markerikson commentedon Feb 21, 2023
I'm gonna do the annoying "+1" thing - this is something I'd love to see added to the React packages! (and tbh it's kind of surprising it hasn't been yet.) I've spent a fair amount of time needing to debug into the guts of React, and it would be a lot easier to do that if the prod builds actually included sourcemaps. (I know that this would increase the size of the published packages on NPM, but hopefully it would be worth it!)
markerikson commentedon Mar 14, 2023
Brian asked Dan about this on Twitter:
Dan's willing to look at a PR, but A) have to stick with Closure Compiler and not switch to Terser, B) there's concerns over "commitment" to keep them working vs hypothetical future build tooling changes.
I'm willing to take a stab at a new PR to get sourcemaps working with Closure Compiler, and will try to take a look at that later this week.
markerikson commentedon Mar 17, 2023
Good news, folks! As of a few minutes ago, I have:
react-server-dom-webpack-serverartifacts)mainwith Rollup 2.xHere's a screenshot of a random function from within the
react-dom.production.jsbundle:I've got a bunch of cleanup and additional verification to do, but I'm fairly positive I have this working as desired.
Overall, I think there's 3 PRs that ought to be merged:
I'll see if I can file the cleanup PR early Monday, and hopefully we can get the Rollup 3.x PR in shortly after that.
(Alternately, I could do all these in one PR. It's not that many additional changes. It's just nice to have more granular traceability to why each change was made.)
update
After discussing with Dan, I'm going to file the 3 separate PRs myself on Monday. Those will supersede the existing stale "generate sourcemaps" PR and the existing "Rollup 3.x" PR, and I can work on getting those pushed through ASAP.
markerikson commentedon Mar 20, 2023
Okay, I just filed #26446 , which adds the sourcemap generation to React's build config!
That should hopefully generate some packages via CodeSandbox CI in a few minutes, and we can now test out that the sourcemaps actually get included and do something useful :)
Generate sourcemaps for production build artifacts (#26446)
Generate sourcemaps for production build artifacts (#26446)
0xdevalias commentedon Dec 1, 2023
For those of us who were interested in sourcemap support for easier debugging/etc, just wanted to highlight 2 other issues that would improve things even more that you might like to watch/support:
x_google_ignoreList(Ignore-listing code) support to sourcemaps #27774Update Rollup and related plugins to their most recent versions (#24916)
Generate sourcemaps for production build artifacts (react#26446)
Generate sourcemaps for production build artifacts (#26446)