Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll

Debugging JavaScript in the Browser

Preview

Start a free Courses trial
to watch this video

Sign up for Treehouse

Basic and Conditional Line Breakpoints

6:58 with Joel Kraft

Setting breakpoints on specific lines may be the most common ones you'll set.

Covered in this Video

  • Line breakpoint
  • Conditional line breakpoint

Equality vs. Identity ( == vs. === )

While == (equality operator) and === (identity operator) might seem to do basically the same thing in JavaScript, many developers prefer using === to ==. The reason is that in certain cases, predicting how == will behave can be counterintuitive. That's because the interpreter will make assumptions about how to treat the values you place on either side of ==.

For example, consider

12 == '12'  // true

Here, the interpreter will convert the string on the right to a number before comparing the two values and return true as a result. It's kind of saying, "I think you meant to give me a number for this second value. That's ok, I'll just change it for you."

Leaving ambiguity up to the interpreter to decide for you can lead to trouble in ways that are hard to predict. Moreover, bugs having to do with these assumptions can be hard to find!

That's why developers often prefer === for comparing values.

12 === '12' // false
12 === 12   // true

It helps them write code that's easy to understand, not only at the time of writing but later when reading back over the code.

Here's an MDN article on this topic for a little more depth.

Related Discussions

Have questions about this video? Start a discussion with the community and Treehouse staff.

Sign up

    Related Discussions

    Have questions about this video? Start a discussion with the community and Treehouse staff.

    Sign up

    There's another bug in this program as well. 0:00
    If I check the Hide checkbox, all the guests who haven't 0:03
    RSVPd should disappear from the page, but they don't disappear. 0:07
    Instead, they become highlighted as if they were confirmed. 0:13
    No further changes happen when I check or uncheck this box. 0:17
    Let's inspect one of these items to see what may be happening. 0:23
    I'll refresh and inspect Tammy's list item in the elements tab. 0:27
    Now I will check the hide box again. 0:38
    And you can see there's a problem here. 0:42
    All of the guests who were not marked responded have been 0:44
    added the class of responded. 0:49
    And they also should be getting an inline display property of 0:51
    none to make them hide from the page. 0:56
    But that's not happening, which you can see here. 0:59
    And you can also confirm that by looking down at its display property right here. 1:02
    It's still list-item. 1:08
    Setting an event listener breakpoint worked really well before, 1:10
    so let's do it again here. 1:14
    I'll go to the sources tab. 1:16
    Set the breakpoint. 1:19
    And it looks like it's already set from before, so 1:23
    I'll leave the change event checked. 1:26
    Now, I'll refresh and check the hide box. 1:29
    The debugger's paused where the listener begins on line 17. 1:34
    Before we start stepping through the program, 1:39
    I'm immediately curious about what's happening in this for loop down here. 1:42
    And that's because that's where the list items are being manipulated in our code. 1:47
    We can jump to a specific line of code by setting a breakpoint. 1:53
    While we previously set breakpoints on browser events, 1:58
    this time we'll set one on a line. 2:01
    To set a breakpoint click the line number where you want to break at. 2:04
    Let's put our breakpoint on the line right after line 22 where 2:09
    the list item is set up in the loop. 2:14
    So line 23. 2:16
    We can do this by clicking on 23 and to remove a breakpoint, 2:18
    I'll just click it again. 2:22
    And I'll put it back. 2:25
    Now any time the JavaScript interpreter reaches this point, 2:26
    it will pause right here. 2:30
    You don't need to step through each line of code from 17 down to 23 either. 2:31
    The play button right here and pauses the interpreter letting it run until 2:37
    it reaches a breakpoint or the end of the program. 2:41
    I'll press the play button now, see how it jump down there? 2:45
    Now we're inside the first time through the loop. 2:50
    You can tell because i is set to 0. 2:53
    Also, if we hover over the li element in the scope window, 2:58
    you can see the first name highlighted on the page. 3:03
    Because our bug only affects unchecked guests, though, we might want to jump 3:06
    ahead until we get to the fourth guest to see what is happening. 3:11
    If I press play again, the loop will cycle around and land on the breakpoint. 3:15
    Now i: 1 and li points to the second list item. 3:23
    I'll press play two more times, and now we've landed on our unchecked guest. 3:29
    Let's say we had a list of 200 guests though and 3:36
    our bug only showed up at number 175. 3:40
    That would mean we'd need to press the play button 175 times. 3:43
    Fortunately, dev tools also lets us set a breakpoint 3:49
    that will only pause if a certain condition is met. 3:52
    Let's refresh this page and I'll show you how it works. 3:57
    I'll go ahead and check the box to pause the execution at the top of our handler. 4:01
    I'll click this breakpoint off. 4:07
    Then I'll right-click line 23 and choose Add conditional breakpoint. 4:10
    I can enter any condition here like 4:16
    lI.classname is not equal to responded. 4:21
    Now when I hit play, the loop won't stop until we get to the first 4:28
    lI element without a responded class. 4:32
    I'll hit enter to set our breakpoint, and now I'll hit play. 4:35
    And we can verify it worked by hovering over the value and 4:41
    you can see the fourth li is highlighted. 4:45
    Now let me just show you one thing. 4:48
    If I edit the breakpoint, we could've added any expression in here. 4:51
    The same thing would've happened if we'd used i is strictly equal to 3, 4:56
    for example. 5:01
    If possible, though, it's better to pick an expression that gets you directly to 5:03
    the situation you're diagnosing. 5:07
    In this case, it's when an element is missing a certain class name. 5:11
    I'll step forward now and 5:17
    we'll expect to jump into the else clause of this if statement. 5:19
    That's because the current list item's class name is not responded. 5:23
    But the first branch is executing. 5:29
    Moreover, the style of the element has changed and over in scope, 5:32
    I can see that the class of responded has been added. 5:37
    Can you spot the bug? 5:40
    The single equal sign is an assignment operator. 5:44
    It assigns the class to that element. 5:48
    But it should be testing the condition using an equality operator. 5:51
    So this should be three equal signs and not just one. 5:55
    If you're wondering why three and not two, see the teacher's notes for 5:59
    a more detailed discussion of the two operators. 6:02
    I'll refresh, switch over to my editor. 6:05
    And on line 23, I'll add the two more equals signs and save and 6:09
    I'll switch back. 6:14
    And now I'll disable all my breakpoints so 6:18
    I can see if it's fixed or not and I'll check the hide box. 6:21
    I need to refresh. 6:28
    Now I'll check the hide box. 6:30
    And you can see it works. 6:33
    Let's review what we learned in this video. 6:37
    We looked at two kinds of break points you can set on lines of your program. 6:40
    A line breakpoint, and a conditional line breakpoint. 6:45
    You'll probably use these a lot in your debugging process because they're so 6:49
    versatile. 6:53
    In the next video I'll show you how to debug functions. 6:54

    You need to sign up for Treehouse in order to download course files.

    Sign up

      You need to sign up for Treehouse in order to set up Workspace

      Sign up