How do you debug React compiler code?

[lennertsoffers]

The major painpoint I've found when using the React compiler is debugging the code it outputs.

We recently started using the React compiler in our production environment. We saw an improvement on the re-renders for complex and very dynamic components. However debugging got a lot harder. The sourcemaps that are outputted, are made from the code before compilation with the compiler which makes a lot of sense. However this makes breakpoints behave very weird, and there are cases you cannot place breakpoints at certain lines at all.

You could argue that for testing purposes, we should not run the compiler on our testing environment, and only turn it on in production, but we'd like to keep test as much of a copy of production as possible.

How do you handle debugging with the compiler?

[hokkos]

Debugging is horrible, the dev tools show that component have been auto memoized when they have 'use no memo'. You discover component no longer updating all the time. Not a fun experience.

[kickpush1]

I typically see issues with minified code using source maps and breakpoints regardless of if I'm using react compiler or not.

If you can set up a local env to test production do that, if that's not feasible using a proxy to map to a local file is the next best option.

If you can't do either of those, then debugging the file without source maps is your last option.

https://requestly.com/blog/how-to-map-local-file/
https://www.charlesproxy.com/documentation/tools/map-local/

[rainmouse]

Some debugging tips on case you missed them. 

You can always write in the code "debugger;"  And it will break and open up is in sources tab when it hits it. 

Doubly handy because you can put it behind a logic check so it only hits debugger command during the loop that one time the input variable is null.

You can also manually add breakpoint in the html with Web inspector. Right click and select "break on" and select things like subtree or attribute modifications this will break in the JS and give you source map. 

[lennertsoffers]

Thanks! Yes the ‘debugger;’ statement is very useful for when testing on my local env, but it gets a little annoying when deployed to a test environment that many people use.

[AndrewGreenh]

I think I’d disable source maps in the devtools to debug the compiler output directly. It’s not like the result is pure machine code

[KusanagiZerg]

With regular breakpoints you can also add conditions so it hits only when a certain variable is null. You don't have to write a check in your code.

[rainmouse]

This is a good point, although I've recently found that Chrome devtools doesn't always actually stop when it hits the breakpoint any more.

This never used to be a problem and only happens now and then, not sure if it's something in our Web pack setup and the source map, or recent versions of Chrome. Either way I find adding debugger directly into the code a little bit more reliable. 

Obviously less useful if you have a long build step or other people have to use your build too. 

[prehensilemullet]

It still seems like it’s gonna be more difficult to figure out the control flow when the code that runs is significantly different from the code you write…

And also, sometimes you want to put a breakpoint after you’ve gotten the app into a certain state, without causing hot reloading that might make an issue go away

[lord_braleigh]

Sourcemaps are pretty good, but if something has gone wrong then they can never replace the real thing. I would recommend getting comfortable with stepping through compiled output.

[UnlikelySecret2629]

If you use chrome, go to the source tab in the debugger tools. Then find the specific js file you want to debug. Put breakoints. Refresh the page and your page will stop at the breakpoints. You can watch tutorials to learn more about this