Cancellation and Promises

[00:00:00]
>> Jafar Husain: And retries perhaps. This simple little operator is one of the big reasons why observables are a lot more expressive and powerful. For front end work in my opinion than promises. And so we'll talk about promises later. But we're not going to go too deeply into promises in this class.

[00:00:15]
It's one thing I want to talk about in the outset because a lot of you I think saw, those of you who read the course description probably noticed that one of the things we were gonna focus on in this class is async/await, and how promises and observables interact.

[00:00:27]
I'm not gonna be doing that. Part of the reason for that is, who here has heard of promise cancellation? Anybody? So, there is a proposal in front of the TC39 JavaScript Committee, on which I sit. As well as a bunch of other folks from Google and Mozilla, for enabling the cancellation of promises, and unfortunately that fell through.

[00:00:48]
So, as of today, you can't cancel promises. Does anybody find that to be a problem, big deal, not a big deal. So in general for front end work, cancellation is not a rare thing. In fact it happens all the time. The thing about users, they're fickle. They change their minds all the time.

[00:01:09]
So in practice what ends up happening is if you use promises and now I've worked with developers on at least three midsized to large projects who have used promises everywhere. And they very rapidly run into this problem which is wait the user hit the back button right? So remember that example we talked about earlier where I'll go to a form and then you show a loading bar and then you make a request to load the data for that form and then somebody hits back?

[00:01:34]
How do you handle that if it's a promise? Anybody have any ideas how we would handle that with a promise? Let's say you've created a promise that's gonna resolve, it's called resolve when it calls your call back, when that data comes back from the server. Anybody have any ideas about how we could avoid doing all the work associated with that promise being resolved, creating all those form elements, showing the screen, etc.?

[00:01:55]
Anybody have any ideas?
>> Speaker 2: Use Bluebird that has cancelable promises?
>> Jafar Husain: That's a good one. Right, you could always use bluebird. Unfortunately, that's not gonna integrate well necessarily with all the promises on the web that are not cancelable, right, or the native promises. And so Bluebird has the notion of cancelable promises.

[00:02:11]
For a variety of reasons, the committee has decided not to go in that particular direction. So in absence of the deus ex machina of using a third party library, how would we cancel? Or if we can't cancel a promise, the best we can do is we can just ignore it, right?

[00:02:31]
So how would we ignore it? Like I wanna drum up some ideas here. How would I remember to ignore a promise? How I would I remember that somebody's left the screen and I don't care about this promise anymore, what would I do? How do we remember the current subscription?

[00:02:45]
>> Speaker 2: Can you use a closed state?
>> Jafar Husain: Yeah, you can close and state. And in fact, that is generally how this problem is solved. People build up all these fancy promise-based abstractions. And they use async/await, which is some very, very nice syntax for something you probably shouldn't be doing on the front end.

[00:02:59]
And that's why it's so dangerous. So, this new study today the new fancy syntax of async/await is so really nice, and pretty, and easy to use, and you probably shouldn't use if for most use cases in the UI. That is a pretty dangerous thing, so the committee has put ourselves in a position where we've built some very, very nice attractive syntax for patterns that are probably not a good idea on the front end.

[00:03:22]
Does anybody love promises and they think I'm just way off base here and I just don't get it and they wanna push back
>> Speaker 2: You changed my mind today.
>> Jafar Husain: I changed your mind today. Well we're gonna see how something like switch latest is able to handle this without any state, right?

[00:03:43]
The idea behind switch latest but we see inside of operators like retry it's perfectly alright to have but basically we make the state somebody else's problem, that's my favorite kind of problem. It's the problem of the RX library, but our code, as we'll see later, contains nothing but consts.

[00:03:59]
All we're gonna be doing is defining things and letting RX worry about all the state internally. And because of the shape of observable, and the fact that it's got this unsubscribe concept that we've been building, it allows us to do that with something like switchLatest. Promise unfortunately does not have that.

[00:04:15]
And so while people want to build these nice declarative UIs, they find themselves storing a bunch of state which is exactly, what we're trying to get rid of. Because shared mutable state, shared state where two independent asynchronous concurrent processes are looking at the same piece of state and modifying them at the same time, it's perhaps the number one source of bugs in concurrent apps.

[00:04:37]
And so while promises were trying to get you to write more declarative code, in practice you end up writing just as much imperative code in UIs at least today, because you're always trying to keep state to just keep track of what you don't really care about anymore. And observable says, well, why have state to keep track of what you don't care about?

[00:04:55]
Just get rid of it, right? And we're gonna see how that's done, but I think you already have a little bit of an idea about how switch latest enables that. If we had had promise cancellation in the language, I would be talking to you right now about how to integrate between cancelable promises and observable and used certain things for promises and certain things for observables.

[00:05:15]
Today in my official guidance to you is please don't use promises on the front end. Despite the fact that they've got a really nice syntax with async/await, they are probably setting yourself up for failure.