Transcript from the "Observables & Headers" Lesson
>> Lukas Ruebbelke: You'll notice here we have this two premise. And so this was a big deal when people were switching to angular two. Now, not so much I don't think. But coming from one dot ex,
>> Lukas Ruebbelke: In working with premises going to observables, that can be a little overwhelming.
[00:00:21] So I know initially there was quite a bit of resistance of why would I even use an observable over a promise? They do almost the same thing in this context. So if that's the case, no problem. You just converse your observable to a promise. I think and a reason why you would use this is if you were doing a hybrid app of angular JS and Angular, and for consistency sake you want it to deal with a promise exclusively.
[00:00:53] So I think to maintain consistency across an app that's being upgraded or running in hybrid mode may make sense. So there's always, you think, why would anybody do this? And somebody invariably comes up with maybe a good reason. But diving into observables, they can be intimidating. And we'll talk about this actually in the next module, but promises kind of do one thing, observables do a ton of things.
[00:01:22] And so, kind of making that switch, it can be intimidating. So What you can do is you can just turn your observable into a promise using toPromise and from there .then and .catch. It works just like pretty much how you would use in in your JS.
>> Lukas Ruebbelke: So, we're just doing a .get.
[00:01:42] We're using .map so what we're doing is we're converting the response to json. And then we're just converting that to a promise in returning it.
>> Lukas Ruebbelke: So http in angular versus AngularJS, it's actually doing a little bit less. So Angular as a whole, they say we're going to focus on the things that matter.
[00:02:03] And we're actually gonna pull back and not get involved in some of the things that maybe do not matter or we wanna let developers have the option to do it themselves. So http is one of those things where under the hood they, at least in this module, they're going ahead and letting you convert that to whatever you want.
[00:02:24] So you could say I don't want it to be json. I want it to just be raw or want to handle this on our end. I want to. In this case we're converting it to json.
>> Lukas Ruebbelke: And so you can see here, we're calling it, we're taking the response.
[00:02:38] And then we are just converting it to a promise.
>> Lukas Ruebbelke: Now, what's interesting is if you've done AngularJS, it's just then, just take the payload and assign it to a local,
>> Lukas Ruebbelke: Property. Now, that's enough about promises. Let's talk about observables, so simply Observable.subscribe. So Observable.subscribe is kind of the equivalent of promise.then.
[00:03:12] In other words you finalize an observable stream by calling .subscribe. Now, within .subscribe you have three methods that you can use. So onNext, so this is anytime a new value is available. This gets called onError, so if something goes wrong, this is where you would capture it, and onComplete.
[00:03:34] So this is kind of like .next, .error, .finally. So this is kind of the equivalent or, orThen, error, and finally is next, error, and aren't complete. But these all get stacked together within the subscribed block. So it takes perimeters. So it's next error and complete. So in this case we're still dealing with the observables, so it's .map.
[00:04:02] And in the,
>> Lukas Ruebbelke: Consuming component, let's say it's just .subscribe. So .promise, or .then, .subscribe, nothing changes.
>> Lukas Ruebbelke: The difference is, in this case, I would say it's actually less work to not have to convert it to a promise. If all you're doing is pulling in some data structure from a breast API, .map here and subscribe.
>> Speaker 2: So what is the catch for that?
>> Lukas Ruebbelke: So none in here, I'll show it you in just a second.
>> Speaker 2: Okay.
>> Lukas Ruebbelke: But if you're going to put it in, it would be,
>> Lukas Ruebbelke: So this is your first function, it would be comma. Or what you need to do is actually turn this into brackets and it would be comma and then the catch would go, and actually it's not the catch it's the air.
[00:05:05] So the air method would go as the second parameter in that.
>> Speaker 2: [INAUDIBLE]
>> Lukas Ruebbelke: Yep, and so we'll see that in just a moment.
>> Lukas Ruebbelke: So we have a RequestOptions object and this has a headers property. So occasionally you need to adjust the header of a request is you're sending it to the server.
[00:05:27] So one, a good example is if you're handling JWT or JWT web token authorization you need to put that in the header. So you can do it in the request options object. Another use case for this that I ran into is setting content type. So is some cases actually writing back to the server you can say, hey, this is what I'm giving you, so heads up.
[00:05:52] It is something like application JSON's. So being able to communicate what's happening in the headers is a pretty common thing that you'll need to do. I'm gonna show you two examples of this. The first one is kind of easy mode. And I'm just creating this generic object over here.
>> Lukas Ruebbelke: And it's an object literal and I'm just assigning a header as a property. And then I'm just doing new headers and I'm just putting in the object. And then from there, when I call host I'm just adding this in as a third parameter. Pretty simple, I could have actually done this in line.
[00:06:32] I extracted it out so it's available for additional calls. You can take the fancy way and you can create a new header object. And then you can just pass it in to the request options. So you basically knew that as well. I've that both ways.
>> Lukas Ruebbelke: Again, I don't know if there's an advantage for one or the other.
[00:06:58] I probably would just go with these one. I think even in the docks, this is kind of what they have. But if for some reason you maybe needed some additional options for the request you might be able to do it there. So outside of the headers, possibly.
>> Lukas Ruebbelke: All right, error handling.
[00:07:16] So this is pretty interesting. So,
>> Lukas Ruebbelke: Unlike promises when something went wrong it would basically just call that error and you would handle it in there. In this case you need to catch the error at the service level. So within the stream you need to say something went wrong, Observable.catch.
[00:07:42] So you're saying if something goes wrong .catch. It will capture that and then from there you can figure out what you wanna do. If you want to surface that error, then you call Observable.throw. And then that will fire the error handler. What this allows you to do is for instance, using promises, if you made a call to a server and it failed and you wanted to retry, how would you do that using promises?
[00:08:16] You can't. You just simply have to redo the call.
>> Lukas Ruebbelke: With observables it's easy. So you can simply say hey, this thing happened, let's go ahead and just retry it three times or whatever. And so now you can say this error happened but I wanna handle it within the stream.
>> Lukas Ruebbelke: For maybe a certain, there's some protocol. Okay, let's try this five times. Then if it fails on the fifth try then we'll go ahead and let the user know. So you may be dealing with kind of a volatile connection that you would actually like to try it a few times.
[00:08:58] So from there you catch the error, something went wrong. You can handle it however you want, but if you want to service it, then you use Observable.throw. And then then that will show up in their handler. So what this looks like is we're making the call. And there's an error.
[00:09:18] Something goes wrong. And so we're saying .catch. So when I say Observable.catch, catch is an operator. And in this case we're saying immediately when it happens let's just let's throw it. So we're using Observable.throw. And this over here is,
>> Lukas Ruebbelke: Going to vary depending on your server. So, I mean it depends on what error object you're getting from your server.
[00:09:46] So if you're on Ruby or .net., so you may get something that could vary. So dial into taste. Whatever you want to hear. So in this case we're assuming that you can convert the error to json and that there is an error property on that. If not then we're just returning the server error.
[00:10:04] So, I'm saying do this or return this. I saw the hand.
>> Speaker 3: So the catch isn't, I guess why are you having to say Observable.throw?
>> Lukas Ruebbelke: Because you can essentially keep that error in the string. In other words, you may choose to not surface it. So for instance, I could say catch the error and instead I'm going to just return like an empty object.
[00:10:38] It gives you the ability to say this has happened and I'm not immediately going to surface it. I'm going to perform some unit of logic in here. And so you just may say, hey if this doesn't work go ahead and just return this other thing in the meantime or do something else.
[00:10:56] And so for here, or you may say go try and update this and if it doesn't work just return the cache version. But in other cases you may say this happened, we need to surface it. And so this is what's happening here. So we're catching it, having a mini of, okay, what do we wanna do, we just broke the lamp on the end table.
[00:11:16] Do we try to fix it before my mom finds it? Or do we actually go tell her? Which would be the equivalent of Observable.throw. That was actually a pretty good analogy for off the top of my head. I'm going to use that more. I mean that's it. What do we want to do here?
[00:11:31] This thing happened. Do we handle it here or try to fix it? Or do we let somebody know? Make sense?
>> Speaker 3: Yeah.
>> Lukas Ruebbelke: And so this is where we have next and error. So the first parameter, so we're just doing this and basically calling it back out. We're saying when this comes in go ahead and call this next function as the first one.
[00:11:56] So we're using bind because of less little scope. Don't worry about that, just know that when next happens It's calling the first function. If there's an error, then it calls the second function. Does that make sense?
>> Lukas Ruebbelke: How do you feel about this?
>> Speaker 4: I think so, I don't know.
>> Lukas Ruebbelke: There was like four, you just had, [CROSSTALK]
>> Speaker 4: Yeah, yeah.
>> Lukas Ruebbelke: A gamut of emotions on your face. [LAUGH]
>> Speaker 4: One more time.
>> Lukas Ruebbelke: One more time, okay.
>> Lukas Ruebbelke: So catch, [CROSSTALK]
>> Speaker 4: Mm-hm.
>> Lukas Ruebbelke: This happens basically at the stream level. So I'm using service here but really what's happening in this stream somethings went wrong, we wanna catch it.
[00:12:42] So you can think of this even as an assembly line. You have your, if something is not right, catch it. From there we then determine do we let somebody know. That's what Observable.throw is.
>> Speaker 4: Right.
>> Lukas Ruebbelke: Makes sense?
>> Speaker 4: Yes.
>> Lukas Ruebbelke: Okay, this is, as far as I know, not possible with observable or promises.
[00:13:04] But the level of control that we can exert on this and how we can handle this with retrying these different things, it's incredibly powerful to do it this way. In fact, one of my favorite Frontend Masters Course is by Jafar Hussein talking about programming, and he is core contributor to Your Reactive extensions.
[00:13:27] And one of the things they've tried to solve at Netflix is, what do you do when you make a call to the server and it doesn't work? How do you retry? With observables it's really easy to do that. So,
>> Lukas Ruebbelke: That's why I love them.