Check out a free preview of the full Debugging and Fixing Common JavaScript Errors course

The "Challenge 3: Solution" Lesson is part of the full, Debugging and Fixing Common JavaScript Errors course featured in this preview video. Here's what you'd learn in this lesson:

Todd walks through the solution to Challenge 3 by using the Network Inspector, response previews, and JavaScript debugger and then Todd takes questions from students.


Transcript from the "Challenge 3: Solution" Lesson

>> So where we left off was when a user would enter zero characters into the text area and click rent. We would see this for this post 400 bad request to /API/grants. So Chrome has nicely showed it to us into the console, but we can also see this and all kinds of other information about what kind of things we communicate with.

In the network panel, the network. The network panel is really valuable and you can a lot from what goes on it. One of the things that I almost always have on in the network panel is this filter option. The filter option lets you do a bunch of things, one, it lets you only show certain kinds of requests, generally when you're debugging you're trying to figure something out, you don't care about every request that it made.

You only care about maybe what what Ajax requests were fired or what JavaScript files got pulled down, or what images got pulled, or maybe what media got loaded. This allows you to quickly make those kinds of searches. And even within that, the filter text box allows you to quickly find like, what's going on.

So in this case, I can say I was looking for a call to slash API slash rants. And as I start typing that in, I can see my list quickly get filtered down to what's going on. I can also change a bunch of things with how the network acts directly from the network panel.

Like console, it's got a preserve log option so that you don't lose all the network requests. If there was a page, reload. It's also got a disable cache, which does have a performance impact. But there was a good question about this in chat while we were on break is, oftentimes your browser is gonna aggressively try and not make requests when it doesn't have to.

It's gonna try and use a version that it already has of a file. You can turn on disable cache to tell the browser to stop doing that and always make the requests. Always go get the freshest version of the file, which during development time is really helpful to have.

There's lots of other tools, we'll cover this a little bit more in a little while. But now that we've kind of filtered our list down to see the files are the request that has been made. We can see that 400 requests directly in this list. So I can click on it and I can see a bunch of information about what they requested.

I can see that this was a post against this URL. It came back with a 400 bad request. And I can see all kinds of things about that request. I can see what were the headers that we came back from the server with, what were the requests or the headers that we requested the server with.

And what did we send up? So in this case, we sent up a JSON object with text and empty string, which kind of makes sense considering that we didn't add any characters to our textbox. The server comes back with a response, this is a helpful server. It actually tells us what our error message is.

A lot of servers are not so helpful and may not tell you what an error messages The server said 400, you made a bad request. And the bad request description is the text property must not be empty. So the server has a rule that you cannot post an empty rant.

But our client doesn't have that rule and just go ahead and let us do it. So maybe we should prevent ourselves from making silly requests that the server won't be able to accept anyway. So we can use the network panel again as an entry point into our code and understand where in our code is actually making this request.

The initiator column. When you hover over it will actually give you a full stack trace of what the code that was executing did. What the code that was executing to cause this request to be made? I have to kind of shrink this down because there's a lot of things in this stack trace.

But I can see there's a number of things that are grayed out here because we black box them away because it's just wrapper code, things like tracker and jQuery. We probably could have also blackbox backbone js, which is another piece of framework, but this is the first time we've interacted with it.

If we keep pushing all the way back, we see that the first piece of code that is ours that we recognize is this addRantView.js line 27. So we can click in right from here and see what was the last line of our code that executed the cause this network request to be made.

And if this call here, this dot collection, dot create. That must be the call into our framework to actually initiate that network request. So we need to add, some validation around this maybe. So, all of these lines here are dealing with the idea that, hey, something interesting is about to happen.

So we should wrap that up with a check here. So maybe before we'll say if we have a rant with text in it, then do it. And we can take advantage of that truthy false Enos thing that we talked about with the last bug where an empty string will get evaluated to false see, but any truthy will go on through.

Although maybe for safety sake, we should do both things if there is text, and the type of Brant text is a string, just in case for some weird reason, random text could be 42. So with that condition in place, we can take all of those lines they're doing this action and drop them in that conditional tab everything up nice.

And so now we've added a very naive set of client side validation rules is that we will not post this form up, Unless RANT.txt is a truthy value, that is also a string. So let's go ahead and reload the page and see if it still happens. So I enter zero characters into the field and hit RANT.

Nothing's happening. We're not making the requests, right? Cuz we fall out of that conditional. But that's not really great user experience, right? The users clicking this button and like nothing's happening. We're not giving them any feedback. Well, we should probably talk about like a user experience and maybe change the box tread and show a validation message and that sort of thing.

But, for most modern browsers, we could get that for free. We could just add the validation rules directly to the markup and handle this before we even get to the JavaScript later. If we take a look here at this text area, text area is one of the fields that supports the required attribute that was introduced in html5 and it's very well supported.

For so there's not really a good way to just manipulate this inline. So I'm actually gonna punch out to my editor to make this change. I'm gonna take a look at index.html inside of my text editor atom. I'm gonna find our text area itself here. And inside of the text area attribute I'm just gonna add required.

Required is one of a handful attributes that was introduced. That allow you to add simple validation rules in your forms to be executed by the browser itself. You don't need to worry about adding complex validation rules and messaging yourself unless you have to. So I'm gonna save that, And I'm gonna reload this again with that in place.

And now if I attempt to RANT while entering zero characters into that box, the browser itself gives me a helpful validation message. That, hey, this field is required. You have to do something here before I can submit this form. And so if that's an acceptable user experience, you can leave it at that without having to write any custom messaging yourself.

>> So, I was testing it by putting in a space or two and it was also stopping me from posting, is there something that's trailing spaces or?
>> Nope, so I could add a couple of spaces and mine works.
>> Mine worked originally, but then when I added the length equals, I don't know when I went to,

>> If you added the length equals that might be, well no. So here what I added was simply that rant.text is truthy.
>> Right.
>> And I think that was all, that was even in my solution. This is something I just thought of, [LAUGH]
>> I think the solution had the link thing.

>> Yeah, if length is greater than zero, but spaces should still be greater than zero.
>> Yes. If rant.text if it's truthy, And its length is greater than zero which is redundant.
>> So, I had originally tried it a couple of other ways. And at that point I was posting blank texts or blank rants, but now.

>> Now one could argue that, blank strings probably shouldn't be valid. You probably don't wanna enter a space and accept that.
>> I was just wondering if it was being done behind the scenes somewhere that I wasn't aware
>> I don't believe so. But we can we can take a look at the next break and see what's going on there

>> Is that a trim three,
>> Yeah, maybe there was a trim in there somewhere. So the root cause of this bug was a user form validation. Client side validation is one of the most common things that probably all of our apps need to do. In order to save on network calls and to improve the user experience.

We probably want to validate the user input falls within some guidelines before we accept it. We looked at the network inspector. We looked at all the ways we can locate network requests and see information about them. We looked at how to look at the response previews. And we played a little bit more with the JavaScript debugger.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now