Debugging React with Chrome

Daniel Kesler
7 min readJun 5, 2016

--

I’ve noticed that the majority of good articles start with some sort of story or joke. Watch for revisions cause I may add one of those. UPDATE: I still don’t have a good one. UPDATE UPDATE: Still no. UPDATE UPDATE UPDATE: You’ll want to read this in its entirety before you decide if following the steps is actually helpful.

So let’s learn how to debug React with Chrome! If you’re reading this it probably means you currently are convincing yourself that Angular 1 is actually pretty good, and you don’t need to prove anything to anyone. Well don’t take off your immutable pants just yet, I’ve got you covered!

This article is actually perfectly timed, because I have my own React error and boy is it a doozy. We can debug it together. I’ve found that a working knowledge of the Chrome dev tools can really get you out of any web dev bind.

First step is to open your app with Chrome. You’ve probably already tried googling “react app not working” so we can skip that. Try opening your dev tools. The only way to do this is by right clicking somewhere on the page. Then in that little menu that pops up click on ‘Inspect’. The first thing you’ll notice is a painful sensation in the back of your eyes. That’s the default light color scheme of Chrome’s devtools burning your retinas. If you still have your wits about you try closing the devtools via the ‘X’ in the top right corner. Otherwise just turn your computer off.

Many before you have made the same mistake. It’s not a problem though, because somebody else has fixed it. We just need to enable a custom UI theme, which is fairly easy. To do this type in the following address in chrome, chrome://flags. Inside here we can find a variety of rows of text. Scroll down until you find this row.

Ignore the radioactive symbol at the top of the page.

Enable this bad boy. Now get some sunglasses cause we’ll need to open the devtools again. In the top right next to the ‘X’ of retinal salvation there are three dots in a column. Click any one of them, then click Settings and you’ll see on the left side something that says Experiments… Actually, that might not have been the right flag. Let’s try this again. Go back to chrome://flags. You’ll see a lot of text rows with a blue Enable; click on those. Keep clicking until you’ve got them all. While clicking you’ll probably notice a pop up below.

That’s true. This leads me to believe that the first thing we enabled was probably the right one. At this point you can either own it and keep all the flags you’ve enabled or uninstall Chrome. Fast forward to your decision being made and now when you open your devtools, click the dots, and click settings you’ll see on the left side Experiments.

Bad — — — — — — — Good

This means we can install our own color scheme now. I recommend this one. Install it. Didn’t work. Wait, there is still one thing we need to do. Go back to the settings. If you click on the Experiments you should see an option for Allow custom UI themes. Click it. Now the devtools color scheme should be… Well it’s apparently still not working. To be honest this really doesn’t help much with debugging. Let’s move on.

Leave the settings modal thing and click on the Console tab at the top of the devtools window. Hopefully you see some red text and some sort of error message. If not, try deleting a few lines of code cause you’ll need something to go off of. For example here’s what I see in my console.

Don’t worry about the yellow stuff those are called warnings. They are created by console.warn, and they have no meaning. That red stuff though, that looks concerning. Hopefully it’s related to why my entire app doesn’t have any UI. Reading this bad boy let’s me know I have violated an invariant. That’s no good. If somehow, through sheer willpower, I manage to read beyond the colon I can isolate my problem to a certain SearchInput component. The console has done its job for now. It’s time for the Sources tab to take over. Now I can walk you through my debugging process.

Alright, with the Sources tab open I hit cmd + p. After closing the print screen modal, I ensure that I’m actually focused on the sources tab and again hit cmd + p. This opens a file search dialog. I type “search-inpu” but stop typing when it has no matches. It dawns on me that since I’m bundling my code there is no such file. No problem, I’ll just go to my bundle.js file. After opening that up, I begin googling “MEAN stack jobs”. Thankfully one last terrified glance at my bundled code allows me to catch sight of this popup.

Source maps are basically a representation of your code before it was bundled. Even though that code is actually never run in your browser Chrome is willing to pretend that it is. So now we just need to enable source maps. Back to Settings, in the Preferences tab under the header of Sources there’s a convenient ‘Enable JavaScript source maps’ checkbox. Enabled. Still no source maps. Refresh the page. What a relief, typing in “search-inpu” now allows me to go to that file. Thinking back to the error message in my console, I scroll down to my render method to check for errors. Luckily Chrome’s JSX syntax highlighting skills are spot on.

Come to think of it I was a little worried that my aphrodite styles were going to cause problems. I want to make sure that things are still rendering after that top level div. Chrome is awesome and allows me to put breakpoints on certain lines so I can see what’s going on. Let’s go ahead and put a breakpoint on line 15.

Close enough. Now I just refresh the app so I can hit my breakpoint. It doesn’t hit it. Maybe that means it’s dying before that breakpoint. Let’s try line 14 instead and let’s close the tools and reopen them just to be safe. This time I do hit the breakpoint, and suddenly my custom UI has started working. Unfortunately, line 14 is no good since I have no idea what JSX actually is as an expression. Hmmm…

Thankfully my new devtools color scheme working has given me a small confidence boost. Let’s try going to the component above this one, and there we can examine just what we’re importing.

Using the console during a breakpoint is really useful; you can type in variable names to see just what they are. With my breakpoint on line 6 I refresh the page. When my app hits this line I type “SearchInput” into the console. The console didn’t like that, “Uncaught ReferenceError: SearchInput is not defined”. Well……..

I’m not gonna lie; things are looking bleak. My app, which is like Twitter but for surgeons so they can share funny medical stories, doesn’t seem like it’s going to happen. It’s time to for a Hail Mary. Chrome has one last debugging tool: copy your exact error into the address bar and hit enter.

30 minutes of Stack Overflow later….

Okay, so apparently all render methods need to return their JSX. Hence the reason the error message said, “You may have returned undefined, an array or some other invalid object.” A function with no return statement will return one of those three. Once I put that in my SearchInput’s render everything is working just right.

What a journey eh? Hopefully you’ve learned some good things along the way. Since I took the time to write this helpful article I also feel no shame in putting in a plug for an app I’m working on called Surgitter. I may have mentioned it earlier. The short story is sometimes funny things happen during surgery and surgeons need a safe outlet to share these stories. If you have any interest contact me immediately somehow, and I’ll explain investment options.

--

--