Transcript from the "Observables & Headers" Lesson
>> Lukas Ruebbelke: So why would you use observable to promise? So one, diving into observables can be super, super, super, super exclamation point intimidating. That there is a lot going on and it actually requires a mental shift a bit on how you think about the world and how they do works as a whole.
[00:00:29] I'm kind of actually putting this lightly, it really actually took me months to fully appreciate observables. And so they can be intimidating especially coming from 1.x. Sometimes people find it easier to just convert it into a promise to something that they are familiar with. And from there you treat it just like a promise, and so if somebody were dipping their toes into an Angular 2 application.
[00:00:58] And they did this for the sake of getting something up and running, I would not begrudge them. As well as I think in terms of making an HTTP call. Because there is only ever a single response, it's not like a websocket, that most people if HTTP is the context in which they're learning observables,.
[00:01:22] I think it's a really poor place to really flex your muscles on observables, because it's ever only returning a single value. And so I believe it was Chris had a comment, of like why would I use an observable versus a promise. Because it seems like a promise would do the same thing, especially for an HTTP call, to that I agree.
[00:01:46] You do have the ability to stack your transformation operators as well as recover from errors more elegantly when you're using the observable. So you have more control over the stream of data, as opposed to an observable that once it resolves, that's it, game over, that's as far as you go.
[00:02:06] And so I can actually I'll talk about that in a bit more, but as a whole, when you're making the HTTP call, really a promise and observable at face value are pretty close together. But I recommend you must use toPromise, but it's actually quite easy to just use an observable and let's see what this looks like.
[00:02:33] So here, http.get we're mapping the response and over turning a promise. So this is a classic, as if we were doing Angular 1.x. So map toPromise, and just before that we are mapping the response. And then in our component, we are calling load items then .then to resolve and handle that promise.
[00:03:10] So if anybody's done one x, this is pretty much par for the course, this is modus operandi.
>> Lukas Ruebbelke: So let's look at observable.subscribe. So skipping my show notes real quick,
>> Lukas Ruebbelke: loadItems(). In this case, we're not having to convert it to a promise, we're just mapping it. So map, done.
>> Lukas Ruebbelke: And then here, instead of .then, it's .subscribe. So if you even put these on a scale, and you weighed them by line. I think even just using observable.subscribe,
>> Lukas Ruebbelke: You have an extra line in there to actually return it to a promise, but then how you handle it,
>> Lukas Ruebbelke: .then oop, get back here or .subscribe, and they're almost identical at this point. So at which point, unless there is a good reason to use two promise, actually here's an example, or here is one case. That if you have an existing,
>> Lukas Ruebbelke: Maybe service that consumes a service.
[00:04:38] So if you have something like interop, where you are converting kind of this back end service and the consuming service. So let's say you have a service that is completely responsible for communicating to the server. Which is then like you have another intermediary service on top of that.
[00:04:57] Then if that intermediary service, for some reason expects promises then it may make sense to go ahead and convert that into a promise. So you don't have to actually change or effect downstream dependencies. But I had to think a little bit about that specific case as a whole, I would just say bite the bullet and run with .subscribe.
[00:05:24] Cuz on the surface, it acts just like a promise and then it does 50 bazillion other things in the process. All right, so headers, let's talk about these real quick. We can have an optional parameter, and that is a RequestOptions object. And the RequestOptions object has a headers property which is a Headers object.
[00:05:52] So RequestOptions, headers, and then we use the Headers object to set additional parameters that your server cares about, for instance Content-Type. Now let me just switch these around here. So this is a very verbose way of doing this. I'm creating headers, I'd like a Headers object. And then I'm creating a RequestOptions object and then passing in the Headers object that I just created.
[00:06:27] And then in my post and I'm passing that in as that optional perimeter.
>> Lukas Ruebbelke: In this case, because really RequestOptions is just an object. I have went ahead and just kind of shorthand, I'm just creating an object with a Headers property on it. And creating a new Header's object and I'm just passing that in.
[00:06:53] So again these are things that people get religious about. I'm lazy and this is I don't think any clear advantage from doing one to the other that I can think of.
>> Lukas Ruebbelke: So what we're doing, creating essentially an object that serves as a RequestOptions object and we're passing it in as an optional parameter.
>> Lukas Ruebbelke: And the RequestOptions,
>> Lukas Ruebbelke: Version. So error handling. Now children, we should always handle errors. Okay, with that said, you'll notice in my code, I'm actually not really doing that. So for demo code purposes, but if anybody's life or money or livelihood depends on it, we should always handle errors.
[00:07:51] So this is what this looks like, we use Observable.catch to process the error at the service level. And Observable.throw to essentially force that error further up the stream. Then we can use the error handler in subscribe, and the subscribe method to respond to that error at the component level.
[00:08:10] So let me back up a couple of slides. In your subscribe block, this actually handles or takes three methods, onNext, onError and onComplete. So our onNext is when some data is emitted, this will get call and continue to be called, unlike a promise on air. So if something goes wrong, it gets called or onComplete, so when the stream is just done, then this gets called as well.
[00:08:41] So in promise terms, this is next catch and finally. So kind of a similar thing, so going back here.
>> Lukas Ruebbelke: We're using .map again, but in this case we're catching the error. So if something happens, we want to capture it. Then using Observable.throw, we are then sending an error back up the stream.
[00:09:17] So this will get returned in lieu of, or as the value for this observable. And then within our,
>> Lukas Ruebbelke: Hold on. Yes, then within our subscribe block, what we have here is as the error handler or the second parameter, we're calling handleError. And so what this could also look like, cuz I saw this for a second and I did a double take.
>> Lukas Ruebbelke: Is we're kind of handling this inline,
>> Lukas Ruebbelke: But this could also also be for instance,
>> Lukas Ruebbelke: An old function here like,
>> Lukas Ruebbelke: this.doSomethingDrastic.
>> Lukas Ruebbelke: So essentially you just stack these methods up. So on next, onError and onComplete.
>> Lukas Ruebbelke: And so if we had an onComplete handler, what that would look like is.
[00:10:25] And keynote is an amazing IDE by the way. It's so good, I love it.
>> Lukas Ruebbelke: Handle complete.
>> Lukas Ruebbelke: Like this.