Distribute source maps for easier debugging in Chrome's Performance tab

[astoilkov]

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 innerHTML and 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.

[bvaughn]

I don't understand this issue. Why does a minified build prevent you from using the browser's profiling tools?

[astoilkov]

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:

• if I see flushPassiveEffectsImpl() taking a lot of time I know I should look at some of the dispose methods of effects
• if I see a lot of calls to setValueForProperty() then I can think of lowering the number of attributes I am changing
• if I see a lot of time spent inside an anonymous function which parent is updateDOMProperties() then I can change/remove the dangerouslySetInnerHTML

I 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.

[astoilkov]

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]

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?

[astoilkov]

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.

[bvaughn]

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?

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]

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.

Thanks, makes sense.

What do you think about the source maps idea? Are you open to discussing and implementing it?

[bvaughn]

Discussing it seems fine!

[astoilkov]

Adding an issue I found on the topic: Question: Building react with sourcemaps.

[0xdevalias]

I wonder if providing source maps would help address the problem you mention of occasionally needing to step through React internals?

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 .map files 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:

• https://github.com/facebook/react/blob/main/scripts/rollup/build.js#L238

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]

I got this working somewhat, I updated Rollup and all of the plugins, set sourcemaps to true and SourceMaps: true in 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 closure and strip-unused-imports can be replaced by the terser plugin. Sizes could be replaced by https://www.npmjs.com/package/rollup-plugin-sizes

I've had to give up for now though, if anyone else was looking into it that's what i've done