Challenge 8: Solution

[00:00:00]
>> Let's kind of figure this out together. I'm sure there's a couple of different solutions. This was kind of an open ended on how you could solve this. So what I asked you to do was go into the index and just simulate jQuery failing to load by commenting it out, and giving the user some sort of indication that a failure has happened and notify our monitoring that something has gone wrong.

[00:00:25]
So when I comment that out and reload, here is the user experience, uncaught reference error, jQuery is not defined, and it blows up on index index.js line three. This is our main JavaScript function, and the first thing it does is use the JavaScript document ready trek of passing our main function into a jQuery callback.

[00:00:49]
But if jQuery's not there, obviously that's not gonna work, and a whole bunch of other downstream stuff is not gonna work. So, we need to add our check there to handle the case of jQuery not being there. So, there's a couple of different ways you could have solved this.

[00:01:08]
In the theme of how we did the other one, you could just check if there is no such thing as window.$. Then we need to do something. We need to notify our monitoring, which we could do by passing a message into console error. jQuery failed to load. And we need to notify the user that something terrible has happened.

[00:01:36]
And you could do that by popping an alert. You could do that by drawing some markup, you could do that, and there's probably the only two ways I can think of. I don't like alerts for shipping to production. So, I'm going to draw some really simple markup. And I'm just going to say document.body.innerHTML is going to be an h1 tag that says sorry, something terrible happened.

[00:02:06]
Are you in an elevator? Try again and then close our h1 tag. Maybe [LAUGH], maybe add one more thing, div if you have lots of problems, email us hello@getranter.com, people feel good when there is, they have a way to contact you. All right, so with that in place, if we reload this page, At least the user knows that something terrible happened, right?

[00:03:00]
Our critical dependency failed, but we've given them something to know that it failed and we've notified our own system that it failed. And so this is really the best we could do in these circumstances. How could this problem impact you? Let me tell you a little anecdote that definitely did not happen to me.

[00:03:24]
The stripe API, is everybody familiar with stripe, I think I've mentioned them a couple times, it's a really cool like payment transaction provider. It'll just take credit cards really easily. Their JavaScript API. Up until not that long ago. One of the mechanisms that they had to do it was you could drop the JavaScript API onto your page and you would decorate a form.

[00:03:46]
And you'd say, this field in the form is the credit card number. This field in the form is the expiration date. And this field in the form is the CV, the checksum CV two number. And then once you've done that, the stripe library would intercept that form and go and process the credit card for you.

[00:04:04]
It was really slick. It was really good way to do it. Except if Strike:js fails to load. If Strike:js fails to load, you have a form that takes a credit card that nothing is going to intercept it. And the user hits submit, and the form will do what forms do, and they will submit to, if you didn't specify anything, like maybe wouldn't describe what the form is supposed to do if you knew stripe was going to take it over, it would just take all those fields, put them up in the URL, and do a get request back on the URL.

[00:04:38]
Which shows the user, hey, that's not my credit card detail up in the URL, it doesn't make you look very secure. Because in fact, you're not. That is one of many ways that this can bite you. Always anticipate that a library can fail to load, and have a fail back.

[00:04:57]
Even if that fail back is just telling them that you can't proceed. Because nothing's worse than leaving your application in half ready state or in a state worse, that will leak sensitive information. So this error, which is far more common than most people think is a network bug.

[00:05:18]
It can happen because of a poor or unreliable networks like on subways and elevators in crowded areas. It can happen in corporate environments due to nasty corporate proxies that decide to get in the way and like meddle with requests. Or it can happen with invasive browser plugins that can do this a lot of the same things for not always the best purposes.

[00:05:42]
We looked at load checking our assets. And I played a little bit with Charles and Fiddler on how you can simulate different kinds of networks. And those are definitely worth a play, but we, we could spend probably half a day on playing with Charles. So, if you need to do that kind of debugging, I encourage you to look up some literature on that.