DevTools: Profiler: Enable correlating console logs to profiler output (and vice versa)

[czf1998]

A challenge with the React DevTools profiler is that it's too hard to correlate profiler results with console logs. This makes diagnosing and fixing render performance issues much more difficult.

For example, yesterday I was debugging an app where each render usually took 10ms-20ms except every 20-30 renders it'd take 600-800ms. It was frustrating that I didn't have a way to correlate the profiler UI (which told me which renders were problematic) with the verbose console log output that might tell me exactly what went wrong during those renders. Instead I had to comb through logs and guess which output came from "bad" renders. This was tedious and error-prone.

Anyway, my proposal is for React DevTools to make it easy to correlate profiler results with console log output. Both directions would be useful:

1. navigate from logs to profiler - if I see a suspicious line in the logs, I'd like to easily navigate to the profiler with the specific component/commit selected that was running when the line was logged.
2. navigate from profiler to logs - if I see a suspiciously long commit, I'd like to select it in the profiler pane and have an easy way to see associated logs.

I don't have a strong opinion about how this should be accomplished, but below are a few ideas to spur discussion.

A minimal solution could be something like this:
a) The profiler assigns a unique ID to each commit
b) The profiler's right pane would show the ID for each commit
c) React would add a new hook that'd return that ID
d) Userland code could include the ID in logs.

Just this minimal support would be a vast improvement.

If we wanted to make it smoother, here's a few ideas that could be layered on top.

1. Profiler->Console Links The ID in the profiler UI could be a hyperlink that'd open the console drawer and put the ID in the console's CMD+F search box. This would be one-click navigation from profiler to logs. I don't know if Chrome allows this kind of cross-pane control, over the console UI so this might not be practical.

2. Console -> Profiler Links For one-click logging in the other direction., we could have a special URL format (e.g. react://profiler/commit/2c1056b5-1be1-43d4-a105-1d840cf4f9c3) that would enable userland code to emit links in the console that, when clicked, would navigate to the specific commit (in the profile pane) that was active when the logs were emitted. Similar caveat as above: I'm not sure if chrome extensions can be "deeplinked" like this.

3. Log Components Where Building on (1) and (2) above, we could enable console<->profiler linking without requiring changes to userland code. We could have a profiler setting (e.g. "log components where" with UX like "hide components where") that, when active, would emit a line to the console log at the start of each render of a matching component. The output would link back to the profiler, e.g.
   [RDT] Starting MyCoolComponent (react://profiler/commit/2c1056b51be143d4a1051d840cf4f9c3).

What do you think? I'm unfamiliar with React and RDT internals so there might be much better ways to solve log<->profiler correlation than my naive ideas above. But at least I wanted to call out the problem and encourage discussion about a solution.

[phb1972]

Would using the React <Profiler> API help at all here?

[phb1972]

Would using the React <Profiler> API help at all here?

https://reactjs.org/docs/profiler.html

[pkf1994]

@pkf1994 - I know which component is having the problem, but I don't know which one of 100+ renders of that component (it's re-rendered in response to IntersectionObserver callbacks during scrolling, so it renders frequently!) is the problematic one. What's missing is a way to correlate a specific problematic component & commit pair to the logs emitted during that the render(s) and effect(s) that were part of that commit. Ideally, once that basic capability existed, it'd also be easy in the DevTools UI to navigate back and forth between the profiler view (which is the easiest way to identify problematic component/render pairs) to the logs which can provide more detailed diagnostic info about what's happening during a specific render.

@czf1998 - I guess I could roll my own poor-man's implementation of what the the RDT profiler does by measuring the render of every component that I suspect of causing the problem and logging the results, but that seems like a pretty heavyweight userland solution. Seems like it could be a lot easier with some small tweaks to RDT. Or do you have some other simpler solution in mind that I'm not thinking of?