Progressive Web Applications and Offline Reviewing Async Methods

[00:00:00]
>> Steve: So we've talked about promises. We've seen how to use a promise to wrap something that might be asynchronous, all right? And it's interesting, like Mike was saying, someone might be like why wouldn't you send that to the server? Why are you doing all of this message to a thread and get a message back from a thread?

[00:00:15] Cuz that is totally different than sending it to a server. So [LAUGH] yeah, so it's the same amount of complexity, but you do get all of these advantages of having client side, right? But sometimes you do need to talk to a server, and we're gonna talk about some patterns for that.

[00:00:32] Talking to servers has had a long storied history in client-side engineering. Obviously, any time that you think to yourself, the web is hard and, or possibly broken irreparably. Remember that it is a document viewer from the 1990s that we turned into the world's largest distributed platform. [LAUGH] Just remember that nobody sold it to us.

[00:00:57] So originally, you requested a page, you got a page. That was the promise that Tim Burners-Lee gave you. Right, and that's what you got in the early 90s. Then through some historical oddities, Microsoft gave us XHRHttpRequest, a story that I'm happy to share later. And this gave us the ability to fetch additional data without dumping out the entire page and getting a new one, right?

[00:01:26] And this was monumental, this is a fundamental building block of the modern web, that you don't toss out the entire page you had just to see if there's a new email, or anything along those lines. But hey, ask the server anything new, get it, put it on the page.

[00:01:41] It's the reason that you have things like JML. You have almost all, well, we think of web applications rather than pages are built on top of this horrid API. So this is the ancient way, and if you've never seen this, one, thank your lucky stars. Because as soon as we could come up with an abstraction around this we stopped doing it.

[00:02:00] But what you do is you create a new XMLHttpRequest. Don't worry if you're getting JSON or anything else, it's an XMLHttpRequest, cuz that was good naming. You would then open it with the method and the URL that you wanted to retrieve. You would then set the response type, and then you'd add two event listeners, an onload event listener, and an onerror event listener.

[00:02:23] And you're arguing like hey, it looks like you're using a feature from the early mid-2000s and ES6 at the same time. It's hard to get all of this on a slide.
>> Speaker 2: [LAUGH]
>> Steve: And then after you added all those event listeners, you would go ahead and send it, which would then call one of the above written event listeners.

[00:02:42] And you would write all these lines every time. And so over time we've came up with patterns to abstract around those, the first being the call back pattern, right? How about you just give me a method and a URL, I will do all of this and I will call whatever function you handed me on the onload and onerrors, right?

[00:02:59] So we gave ourselves an abstraction. More recently we've had, as we saw before, a promise-based API, but this is still an abstraction around XMLHttpRequest. This has basically hid all the gory details and gave you the exact same thing with a nicer API. And there are some issues here we don't have a lot of control over the request and response.

[00:03:22] We make one, can't really modify or do anything with it. We get a response, but it's usually just the JSON that came back, or the XML if you're unlucky. And it wasn't really made for what we're trying to do, you can only get certain types of data types.

[00:03:40] Let's say, there are other things you might wanna get from a server. Images, video, literally anything that's just not XML or JSON, and JSON's not even in the name, right, that just happens to be a lucky break that you can also get JSON from it.