Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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.
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