It’s common to use console.log in your code as a quick way to ‘debug’ and determine the value of a variable, or where and if a function is being called. It’s straightforward and works the same way in every browser. It almost seems like a waste of time to use anything else. BUT, once you learn to use breakpoints and have an idea of what they can do, the console.log’s will be like acid in your eyes.

I want to keep this short, so here’s a link to a live example so you can follow along: sesamechicken.github.io/react-startup, and the repo for it here. I’m using Chrome for this, but you can use the browser of your choice.

Our test code is a simple React app which shows 2 components – one that displays some witty text, and another connected component that will allow you to add items to your grandma’s shopping list.

Since you already console.log, you know how to open the devtools, so let’s do that now. Once open, use cmd + p to open the command palette so we can find the file we want to work with. In this case, we’re using ‘connected_component’.

The connected_component file in the source pane

So, let’s look around for just a sec. There are two functions that actually do things for us. onKeyUp and addListItem.

onKeyUp = (e) => {
    const { value } = e.target;
    e.persist();
    this.setState({ inputValue: value });

    // A little overboard; I'm looking for the ENTER key
    if (e.keyCode === 13) {
      this.addListItem();
      e.target.value = '';
    }
  }

  addListItem = () => {
    const { inputValue } = this.state;
    const { addToList } = this.props;

    addToList(inputValue);
    this.setState({ inputValue: '' });
  }

In console-land, to see if our onKeyUp method is firing properly and that we’re getting the value we expect, we might do a little something like this:

This seems reasonable. In fact, it is. But, we can get the same info by not touching the code, and not waiting for a rebuild/re-render. Let’s take a look…

Attain the same info by not touching the code, and not waiting for a rebuild/re-render.
Adding the breakpoint in the devtools

Breakpoint (line-of-code)
To add a breakpoint, we click in the margin next to the line we want to ‘break’ on, or, pause script execution. When we type into the text input, the function fires and the browser halts at our breakpoint! Not only does it stop, but it provides us with all the information it has up until that moment. As you can see, we can see the value we’re pulling off of e.target, and, we can see the entire event passed to the method!

This is the most basic breakpoint we can add and it covers most use cases for console.log. We have the info we wanted, we didn’t touch the code, we didn’t have to reload the page, and our tools didn’t have to rebuild or re-bundle anything. ?

Once a breakpoint is reached, we need to instruct the browser to move on and continue script execution. We do this by clicking the Resume button in the dev tools or in the viewport.

Alt Textor
Alt Text

Logpoint
Let’s look at another type of breakpoint: logpoint
The logpoint does exactly what you might think: it allows you to log any value you wish from the position you place it in the code into the console. Let’s try it out.

This time, let’s play with the addListItem method and select ‘Add logpoint’ on line #30. You’ll notice a couple things that are different about this type of breakpoint. The first is that you can specify what to log out. The second is that the execution of the code won’t stop when the browser reaches this breakpoint. Try adding ‘value is: ‘ + this.state.inputValue. Now switch over to the console and add some items to your grandma’s list.

Logpoint

Conditional Breakpoint
Building off of the last example, right click on your logpoint, and select ‘Edit breakpoint.’ Change the type from ‘Logpoint’ (via the dropdown above your text to log) to ‘Conditional breakpoint’ and enter the value: this.state.inputValue === ‘oranges’. Now, when you add items to the list, this breakpoint will watch the value. If it strictly equals ‘oranges’, it will stop and pause execution.

There are other breakpoint types available to you, including:

– fetch/XHR
– function
– DOM change/update
– event listener
– maybe more

onKeyUp = (e) => {
    const { value } = e.target;

    // We just added this
    console.log(`I fired! The value is ${value}`); 

    e.persist();
    this.setState({ inputValue: value });

    ...

If you made it this far, I’d like to thank you for reading through my first technical post. I hope you learned something useful. Breakpoints are awesome when you know how to use them and how easy they are (plus you can debug a site that’s in prod and not running locally!). If you have any advice or suggestions on how I may improve my writing or if this helped, please drop a note below!

Keep coding!

More reading:
https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints