JS Remote Conf will run from Thursday, January 14th - Saturday, January 16th. Get your ticket(s) or submit a CFP today!

 

02:27 - Jeff Cross Introduction

02:31 - Rob Wormald Introduction

02:42 - Object.observe() => Dirty Checking

06:22 - Reactive Programming and Reactivity

14:34 - What problem are we solving?

22:45 - Reactive Programming in Angular 2

27:43 - Using Observables/Promises => Observables

 

More on Reactive Programming

Picks

The Miracle Morning: The Not-So-Obvious Secret Guaranteed to Transform Your Life by Hal Elrod (Jeff)
How We'll Live on Mars by Stephen Petranek (Aaron)
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim (Ward)
Relative Finder (Chuck)
FamilySearch (Chuck)
The Introduction to Reactive Programming You've Been Missing by Andre Staltz (Rob)
Cycle.js (Rob)

Special Guests: Jeff Cross and Rob Wormald.

 

[Inaudible] said he’s not shaving until we release beta. [Chuckles] He’s got a nice beard.

I was going to say that’s going to be a long beard.

Hey everybody and welcome to episode 68 of the Adventures in Angular Show. This week on our panel we have Aaron Frost.

Hello!

Ward Bell.

Hello.

I’m Charles Max Wood from Devchat.tv. I want to do a quick shout-out for jsremoteconf.com. We’re looking for speakers and attendees so if you want to speak or you want to attend, go to jsremoteconf.com.

We also have two special guests. We have Jeff Cross.

Hello.

We also have Rob Wormald.

Hello.

So we brought you guys along to talk about Angular 2 and I think the interesting thing that we were discussing on the mailing list was Reactive programming in Angular 2. And now I’m really curious what you have to say because object out of observed got yanked out of the specs.

A while back when Object.observe() was spec we were pretty excited about it and we’ve done some designs with it and looked at it but we abandoned that idea a long time ago. There are a lot of performance implications with it that were not favourable for what we wanted to do. We made change detection faster than it was in Angular 1 but I wasn’t too sad to see Object.observe() go.

I dismissed it as soon as I realized it didn’t do anything with define properties.

Yeah.

So what are we stuck with? I mean, what are we going to use now?

For Angular or in general?

Yes.

We’ve got – in Angular 2 we still have dirty checking but it’s more optimized and it’s much faster and it’s more pluggable than it was in Angular 1. It’s actually really fast; I’ve got some good benchmarks showing that.

Then, you have more than dirty checking. You have two other options.

What are the other options? [Crosstalk]

I was going to say its support for immutability and for an observable object. Is that changed? I don’t mean object out of observe.

So those are ways to tell change detection. Whether or not to dirty check something and also to tell it. It’s essentially new ways to tell whether or not you could skip over this during dirty checking or not.

So immutability and things like using AC primitives with this idea we call pipes and templates, make it where you can have these bindings to promises or observables in your templates that change detection can automatically know not to dirty check that unless a new value is embedded from the promise of the observable.

That’s big. Or it could be big in certain scenarios. [Crosstalk]

Maybe you should explain that because I still don’t really understand that and I’m supposed to understand that.

I won’t try to explain it and too much – Victor is the genius on it but essentially, you go through the tree of bindings in your app at a given time so all the component, properties that are in your templates they used, those are kept record of in Angular. And it goes through each of those bindings and sees – anytime there’s a change like the user does something or you get some new data from a service, Angular will run change detection which looks at each of these properties, each of these bindings and sees if its value has changed since the last time change detection ran and that’s called dirty checking. It’s the value dirty and different before?

Right, and there’s a huge graph that it could be walking down and being able to clip that graph because you know you don’t have to worry about following anything down a particular path can save on that enormously, so that’s what those other options that we are talking about. They say, “Look at that one, it keeps going,” and I think we’re all familiar in Angular 1 with what happens when you have lots of watches which is essentially what we’re talking about here.

During a digest cycle – you have a digest cycle in A2 really, we don’t have to kick it off. It has to compare prior to current value to prior value. This means fewer comparisons.

Yeah, and in addition to giving more control, it’s actually a lot faster and a lot more memory efficient than scope digest were in Angular 1. Even when you do it after a run, it’s a lot faster and it doesn’t generate a bunch of garbage that has to be collected.

So I feel lost because I thought we were talking about Reactive –.

Sorry.

Maybe I don’t know what Reactive is and so we’re going down this hole – this other tangent of not Reactive unless [crosstalk] what it is, what Reactive is this.

Ward just wants to avoid the subject I think.

No. I’m sorry; I don’t actually know what – when we roll the tape back we’ll figure out how we got here but you’re right Aaron. [Crosstalk]

No, it’s not Ward. It was Chuck.

So actually how do we transition from this to Reactive because I agree, this is not about Reactive at all.

We could throw something in the middle. We could explain the special – it’s awkward to talk about it even sometimes but the special relationship that Jeff and I have.

Oh, is this now the right time?

I mean this is good as any time, we’re trying to transish from a thing to another thing. So Jeff and I have a special relationship – Jeff, why don’t you explain it?

Which relationship is this, our GDE buddy relationship? [Chuckles]

Is there a love child involved? [Crosstalk]

Oh, I should hope so.

There’s no legitimate ones.

Yeah, there’s no legitimate ones but the buddy system.

Okay. Aaron is my GDE buddy which means he and I – how would you explain it – we collaborate. I’m his connection into the Angular Core team and he’s my connection to the outside world. So if I were to know something about what’s outside Google, I just ask Aaron and he enlightens me.

Yeah, you’re the Yoda to his Luke Skywalker kind of thing?

Yeah that’s a good way to say it.

For Googlers, they don’t know how to use Google because it’s just so last year. He asked me nonGoogle things and I googled them to get the answers.

Yeah, I query the index directly sometimes but we don’t have the nice UI that you guys have.

Yeah, exactly.

I’m just so glad we got to reactive this way. [Laughter]

[Inaudible] how he tied us back. Go ahead Aaron.

There we go. So now we’re done explaining that, let’s talk about Reactive.

Yeah, nice.

Smooth. Did you see that? [Laughter]

It’s the most seamless transition I’ve ever heard.

This is why they pay me the bucks folks.

Well, let me give to you my reaction to your love child story. So Rob, pull us out of the fire buddy. What is your vision for Reactive in Angular 2?

Like the segues, all that stuff we just talked about – it’s the same and Angular 2 is not scary and doesn’t change everything that you love in Angular 1. That’s the way that it works. Today it’ll also works but it works better. But you want to do all these shiny new Reactive stuff, we’ve got a bunch of new options for it. [Crosstalk]

Bro, explain reactive stuff because I think a lot of people know Angular and they don’t know any beyond Angular. So I’m thinking a lot of people, myself included, what exactly is Reactive?

Because it’s one thing to be like, “Hey, this is how you do it in Angular but what is it?

So this is the way I’d explain it. You know what a promise is, right? You know how promise works.

Right.

And you know what an array is, you know how an array works, right? So Reactive programming, at least in the way that we talk about it, is about this new thing that’s called an observable. An observable is like a primitive for Reactive programming so if you have a promise and a promise is asynch, like a promise – you do something, it takes some time and then you get a value back. And then an array is a collection of many things, so you have an array of numbers or anything. So an observable is a combination of two things.

We use observables with this idea of observables to make things Reactive. What I mean by that is when you click a button on a screen, typically in Angular 1 that would fire a method and then you call functioning, some other stuff, do some other stuff and you do steps of things. And if you think about it, clicking a button many times is like a collection; you could think about a bunch of button clicks as an array of button clicks.

The way I think about Reactive is that Reactive takes this idea of lots of things happening overtime – button clicks, requests, whatever and lets you think about them like arrays but lets you do asynchronous things at the same time like – this is a terrible explanation as much as I know [inaudible], right?

Let me try something there from where you're going. If you think of it, we think of arrays as a sequence in space and I think of the stream as a sequence in time; it’s almost like an array in time. I think stream is something that people can get their heads around. They can imagine a stream of events flowing at you. You got that Aaron? Does it feel right? [Crosstalk]

Yes.

These things are coming at you and if you could build an array of them where the dimension was time instead of space then you could start saying, “Well, I’ll take the first thing that happen and the next thing that happen and the next thing that happen,” and you’d know what to do. Now, if it’s an array in space, we have things like filter op; we have a filter thing where you say I want everything in the array that is at an even number and you have no problem – none of us who have been in JavaScript for a while are probably going array.filter and then we check each value and say is it odd or even, right? You good? Say yes.

[inaudible].

Yeah. Totes my goats, bro. [Chuckles]

Alright, so I just think of – this is how I think of it is I just say, “Well, I ought to be able to have a filter over an array in time in which I examine each of that as it arrives and decides if it’s interesting to me or not.” And I’d love to have a filter operator over events in time just as I love having a filter operator over an array in space.

There was a time when I didn’t have one of those. There was a time before filter in which I had to manually do everything with the array and there was a time where we know today in which we had to deal with each event as it arrive without any kind of abstraction-like filter but now with Reactive programming we start to have very similar kinds of operators like filter and map itself in which we can deal with streams which I think of as an array in time. That’s my short [inaudible]. What do you think, Rob?

This is a little bit weird and I guess – let’s talk about Reactivity first. Reactivity is about reacting to things that happen. It’s about – the program is pushing stuff to you. So go back to that button click for example, clicking a button a bunch of times – that’s a stream so a stream of button clicks. And each time you get a button click, you got to do something with it so it’s the basic way to think about it. Reactive programming is about dealing with streams of stuff.

So if you think about an Angular application, what you would do is you take a button click and you make a request and you would stick it into your view to get the most basic way of doing things. Reactive programming is just about giving you a tool to deal with all these things the same way so it means you can take a stream of button clicks and like Ward was talking about, turn those button clicks into requests and then turn those requests into responses and turn those responses into UI. It’s that idea of taking a thing that is being pushed to you to something else, change it into something else and putting it into the view. That’s they really basic idea before you get into the mechanics. Reactive programming is just about dealing with streams of stuff and all we’re talking about is giving you the tools to deal with streams of stuff as Ward was talking about filters, maps and all that. So it’s all the stuffs that you do with arrays except you can do events and all that stuff that you know that we do. We’re doing a crappy job explaining this right now. [Chuckles]

So why is it a good thing? What problem are we solving? I think that’s the problem. When I talk to people about Reactive and I’m sure when you do it, it’s like we can immediately dive into how it works without really starting from what does this do for us that I don’t just do today in a call back?

Well because programming is hard but asynchronous programming is hard. There’s a lot of stuff to think about, there’s a lot of stuff that happens outside of what you're doing. You got to worry about call backs, you got to keep things in order and you got to keep – it’s a lot that happens. For me –.

Promises just help with that though, right?

Yup.

Promises – I know Ben [inaudible] is going to get me and punch me in the face for saying that but –.

Promises are definitely an improvement over call backs. It gets hard for things where you're actually reacting to events then you’re call back – it’s hard to express that as a promise because it’s going to happen multiple times.

True. For me promises are great when it’s one and done.

Yeah.

I go and make an XHR request and I expect it to be really simple.

You had to go there Ward.

What – I had do. One and done.

What is XHR? A four letter word.

Oh yes, it is. It is a four letter word with a one – drop that. I make asynchronous request for data and I expect the world to be very nice to me and the server’s always there and it always gives me the value I ask for and everything is good. The world as it really is, the fantasy world we live in, then it’s like I got one event and then I’m done.

So promises make some stuff easier; observables make that even better, how?

Promises are lacking some properties with that that make it hard. For one, they are not cancellable so once you start a promise chain you have to hack out of it. You can’t cancel the rest of the chain by throwing and having some handler at the end of the promise chain that will say there’s an okay thrown they threw inside of the promise just to stop the rest of the work from happening.

So that’s one big thing; with asynch things where you don’t want any more work to be done or you just want to free up resources, then with promises you have to hack around it. And there have been some proposals on – I’m not sure of the state of it proposed – adding abort to promises particularly with the fetch spec because people want to be able to abort requests. I’m not sure where that went. I think there are some fundamental issues with that and that made it difficult.

The other thing is that promises, they do work automatically. If you have a promise, it’s already doing work and when I say ‘do work’ I mean it’s already made an HTTP request or something and you just wait for that promise to resolve with the response and it’s done regardless of if you actually want to do anything with it and that’s usually fine. People design apps knowing that once you trade a promise or make a request, then you’ve already accepted the cost of doing the work. But by deferring the work, something’s actually subscribed to it so if I have an HTTP request, if I just have it there and then wait until people subscribe to actually create the XHR object and execute the request, it opens up doors for how I can architect my application and share things between my application and keep my systems resources better being used to minimal.

Better than things not being promises, I think we argue about that a lot and I think that it’s more about, for me, it’s unification. Promises are really good at HTTP requests but they're not good at events. You can’t describe button clicks as that but you can describe requests in an observable so it allows you to treat all the synch things that you do. So instead of thinking about how events are different than call backs are different than promises are different than events listeners – all these things are different. They have to be handled differently and it means you can’t plug them together really nicely and observables can represent all of these things. You can represent a request with an observable; you can represent button clicks with an observable. And if they’re all the same basic thing, it allows you to hook them up in a really powerful way. It allows you to think about stuff in a single, unified, consistent way. And doing that is probably the biggest practical benefit; you don’t – you can just plug one stream of things into another stream of things into another stream of things. That’s the secret sauce for me is that you can treat button clicks and requests all the same way.

While this all sounds ridiculously complicated – we are trying to explain it poorly, right? It’s way simpler because it’s one thing. You have to learn how it works. You know how that one things works then you just plug them together and that makes stuff way easier.

So essentially, I subscribed over here and I got 10 different things that can subscribe to it and they can all do 10 different things when something happens instead of a string of promises or something else or whatever. And if I generate an entire stream of events, then all of the things that we care about, all the things in that stream can then react properly to get things done including throwing their own events or triggering other processes down the line.

Yup. But with promises too, you can have multiple subscribers.

Oh right.

Yeah, that’s is a strong distinction for me. I think the composability issue is a strong one and it really comes into its own win when you're going to deal with the true stream of events. Like when I make an XHR call, I’m not really thinking about it as a stream; I’m thinking about it as I get one answer and I’m done. I know what Jeff was saying is also true but let’s think about what happens when you make a request of anything and you start getting the results back. I don’t know about you guys but I end up often writing a chain of events – dot then this, dot then that. And inside each of the events is a call back – one or two call backs. Usually one because then at the end I have a big, old catch at the bottom.

And inside there, I’m usually filtering and adjusting and pushing the next thing down the line and I

can do that but it’s kind of clunky – at least I find it kind of clunky. And if instead I could treat that as a stream and I had some nice operators over it, then I’m ready to go with map and filter and write my own delay and retry and I could just chain these things together. And they have semantic meaning instead of having to bury all of that thinking inside of it and I find that ability to chain together operations on a stream to be very friendlier to me as both a leader and a writer of the code. And then as I say, it really comes into its own if I’m expecting that to truly be a stream in which new stuff is coming down overtime rather than expecting only one thing to come down overtime.

So that’s my reaction to it. What did I get wrong there?

Your reaction. So basically it’s not a truck; it’s a series of tubes. It’s kind of how it works.

CHUCK: tubular, dude.

Well that is tubular. I like that – the example that what Jeff and I keep doing – we keep giving talks about these stuff is a typeahead. I think the typeaheads are really a good, basic way to think about this.

So if you start with an input box on the screen, in the old way of doing things you would have a method that everytime that that value change in the box you would call a method and you would make an HTTP request. And like Ward said, you might then take that and then return that, do a then and a then, you probably have a call back and you hook it back into your view.

With the kind of reactive way of thinking about this, we start with these stream of letters. We start with letters – stream of changes coming out of the info box. And all you're really going to do it each one of those little events that’s coming down the stream, you’re going to map it – you're going to use that array operator – you're going to map that into a request and then you're going to take that request and it’s going to map into a response and you're going to response. It’s this flow, this tube of things that makes it really easy to [inaudible] all these things put together. We probably should prepare for this and do a better job. [Laughter]

It’s all good. The way that we discovered the ways to communicate about this will help people

‘okay, so it’s not like this; it is like this’.

When we’re talking about reactive programming in Angular 2, how is that all plugged in to the framework itself so that we get some of these nice things maybe automatically?

Good question.

Are you going to answer the question Rob?

Sure.

That question was very valuable.

Thank you for posing that.

Great segue. So the first thing is forms like Angular 2 forms. We have ng-model that we’re used to and if you like ng-model then cool, keep it. But we also have – forms are observable now; forms are reactive so it’s really easy to basically get a stream of changes from a form. [Inaudible] When you think about it, everytime you type in the box, you're going to name a new input value. So you start with this reactive stream of model changes if you like. So if you use ng-change, it’s like that. Everytime you type into the box, you get a new value in the stream so it starts there and Jeff can take the next step [inaudible].

Oh sure. So I guess we try to approach Angular 2 with two ways of doing most of the things you would do. So you can still write templates like you would with Angular 1 where you can have event bindings where you say on a click event of this element, call this method. But we’re trying to make the duel of that or the inverse of that possible as well by having a reactive way to do all these things. We’re not quite there yet but forms is a good example. You can have imperative APIs where you can have an input element that has change events that you just call a call back and you do something with. Then on the other hand you could get a hold of the observable that it’s already producing and subscribe to that so you can have a nice contained flow instead of handing everything in the call back.

So there are other APIs like the HTTP API which we tested on a little bit. It’s actually observable based so if you make an HTTP request you get an observable back that will emit the response and then complete. And that’s one of the more controversial designs of Angular 2. We had some mailing list where there’s a lot of debate about why should we do this thing that’s most of the time just one off as an observable which is only going to get one response and then complete it. And then I’ll explain a little bit why and then work and say why it’s a bad idea. [Laughter] The main under the bus word.

[Inaudible] You can go back and read that thread and I am one of the most –.

Nobody read that thread.

I’m the most vocal person being, “This is a terrible idea; why would you possibly –. What? You’re going to get rid of promises?” And then here I am six months later writing these stuff, preaching it.

Yeah, that was a good conversation. I wanted to erase all records of it. [Crosstalk] The idea was a couple of things – one is academically, it makes sense that if you're just creating an HTTP request you only want one response from it; a promise nabs well to that but we wanted to compose this HTTP request as part of a pipe line, as part of an existing stream and to give them the benefits of being cancellable and abortable. Like in the example of the typeahead component where as more characters come in to the typeahead, you probably want to cancel the request that’s already pending and also cancel any follow up work that’s pending for a previous query you’ve done for matches for that input. And so we wanted to nab to that and observable is just a nice construct.

But the other part of it was that with Angular 1, the dollar HTTP service, a lot of people have been asking us for progress events for it and to be able to see download progress, upload progress rather than just getting a response when it’s done resolving. With promises, that’s kind of hard. There are ways we could make it work but just the primitive didn’t map well with that.

So with Angular 2, we haven’t implemented it yet but it’s in the design and it is in progress. But we have it where you can actually provide observers to subscribe to these things or to be notified of upload progress and download progress so you can have your loading indicator or some things. So we just decided to just make the observables the basic construct of HTTP request for this purpose and I guess it was one of the major reasons why but Ward can say why he hates that. I’m just kidding, Ward doesn’t hate it. He’s provided a – [crosstalk].

He’s throwing up, he can’t answer it.

Oh, excuse me.

And if you think about it, a promise is just an observable of one value. If you squint a little bit, that’s the way to think about it. Somebody’s going to yell at me about that but if you – really, a promise is just a stream of one value.

That’s classic.

Can we talk about some of the scenarios we did with promises and how you would do those with observables?

I knew you were going to bring this up. [Chuckles]

Yeah. So let’s say we have something simple like I want to go get a customer and then I want to go get that customer’s orders, and then I want to get that customer’s orders details. Not that that’s a great idea but with a promise we do that with then, then, then. How would you that same kind of thing with an observable?

So you’re going to take that first request, right? Just going to give you a response with the customer and then you're going to map that into another request to get the orders from there – customer orders – yeah.

So you're basically going to map or if you want to do multiple request, you're going to flat map or what do we call it now, merge map? Basically, it’s map; you're going to turn that first request or first response into more requests and that’s all a map operation is. And then again do the same thing further down.

So everywhere you did a then before you basically just do a mapping of some kind?

Yeah, you need to do a map which is asynchronous way of doing that or if you're going to do more asynchronous things where the promise you’d use is something like promise.all so if you want to get a list of customers for each one of those customers, make another request, you’d use promise.all and wait for all the different [inaudible].

With an observable, you can use flat map and flat map will allow you to take each of those customers make another asynchronous request and downstream from that have them one by one.

So it’s like an asynchronous map base [inaudible].

And how do you handle error conditions like we did with promises? We could catch things at multiple levels. How do they work with observables?

What do you mean at multiple levels?

So we could have a then which accepts in the first and second paragraph of promise or we can do a thensomething.catchsomething.

Uh-hm. So in observables – when you're consuming an observable, you have your next function which only receives. It’s like – what is it called – internal resolve function not resolved so the success function. So you create a single subscription to an observable, you and your application and that accepts the first organized, your success function. The second argument is your error function and as the third argument which is the completion function that just calls from the observables says ‘I’m done; I’m not going to produce any more values’.

So that’s the promise.then like way of handling errors. And then there’s a catch operator that is also called catch and promises, right? Promise.catch where you can handle errors that way. It’s also more powerful because you can have catches that can actually save the promise or save the observable, return a new one to replace the source observable and recover from it which you can do with promises; it’s just not quite straightforward.

But it sounds like if I’m seeing syntax because what we do in promises a lot we would have – what if our success condition also cause an error. That’s how we always like to do the .catch error anyway. Sounds like we’ve been doing same thing as observables though.

Yup.

There aren’t as many – I guess you could do catches at intermediary steps to catch specific errors that happen at that previous steps.

Yeah, it’s the kind of thing you can actually – catch.when or catch something like that which allows you to pick out specific errors to handle, deal with them or filter the ones downstream.

Well it’s more of you want to make sure – for me it’s more of I want to make sure that whether my asynchronous call fail or my success function had some bad, funky code in it, either way I want to catch either of those conditions so that’s why I like to do .catch or promise but it sounds like they're the same kind of thing as observables though.

That reminds me of another reason why we’ve bought observables for HTTP was the retrying of failed requests. If request fails for any reason, I can just use this retry operator to say ‘retry this three times’ and that will try the request up to three times. What it’s doing underneath is catching the error and retrying again. But there’s this retry.when method operator as well where you can actually look at why it failed and get more sophisticated like you could use exponential fall back to start putting more delays on your retries.

This isn’t an [inaudible] about same observables but I think just the general strategy of retrying. I think anybody’s retrying any network calls should always have some kind of logic behind it because you don’t just want to retry forever; that’s asking for trouble.

Yup.

And typically most observable operators will have the basic retry and there’s usually a retry when and retry until right. There’s a couple of various flavors that give you the ability to do specific logic in those things.

Is there retry until denial of the service? [Laughter]

Retry until it explodes.

Do you got it?

The default retry limit’s like 10,000 right? [Crosstalk]

Or better yet retry – oh, I have to retry? I’ll send tent his time. Oh, that fill, I’ll do a hundred this time.

There you go. [Crosstalk]

You could do this stuff within a catch and a promise, right? Because you do all – you could catch the tier fail and then you’ll analyse it and then you decide what kind of thing you want or return which can be the equivalent of retry because you're just issuing the XHR request again assuming that you have the information necessary to do so.

You can do it with call backs, too.

That’s a pretty good basic difference though Ward but that’s another thing to point out is that an observable of a request, let’s say an observable with a mixed HTTP request, you can re-subscribe to that. So you can basically reuse that same observable and run the same logic again and that’s something that you can’t do with a promise. You have to create a new version of that. [Crosstalk]

I have to create a brand new request; the information about the request is usually lost to me unless I’m very careful about what I’m passing along. So if I’m lucky, that response that I got back included the original request so that I would be in a position to reissue the request but it’s very likely that I won’t have exactly what I need in order to reissue it. There are some advantages there and I like the composability of it.

The advantages are subtle when – more subtle when you're talking about something where you're really thinking I’m going to issue one request. Yeah, I may retry it, yeah I may do this and that but ultimately from the consumer’s point of view, I’m expecting to issue this request once and get one result. I think promises are probably pretty good for that. [Crosstalk].

The only value is you say then instead of subscribe. So you use a method you already know and you save five characters.

Well those are very precious. I only have –.

I know they are.

There are so many keystrokes in my life but –.

We should say they play nicely together. It’s not a question of call backs versus promises which play nicely. Observables and promises really interrupt pretty well together. You can start with an observable, you can do a promise in the middle of the stream and that’s fine. They are designed from the beginning to play nicely with each other. So it’s not necessarily an either or situation. If you’ve got a library like the Google Maps API which returns promises already, you don’t have to wrap that in an observable; you can just use that in the middle of the observable string – that works fine.

I could see people writing code. I’m not sure this is a bad thing but I can definitely see people writing code well into Angular 2’s future where there’s both promises and observables mixed in the same code base. [Crosstalk]

I’m not entirely sure that’s a – yeah, I think it’s going to be a pretty common and probably a decent thing to do.

Pretty normal thing to do. You're not going to say – especially in Node land, there’s a lot of stuff that’s just been-ish converting into promises. I don’t think you're advocating ‘let’s go rewrite everything observable all over again’. They play nicely together; they mix and match really, really well.

It’s worth noting that Angular 1, it was hard to incorporate outside asynch libraries with Angular 1 because change detection had no idea to know when they were done. Or when asynch operation is completed. But with Angular 2, we made it a lot more interoperable so you don’t have to use Angular 2’s HTTP library; you can just as easily use fetch that comes in the browser or XML HTTP request and now these responses – [crosstalk] what’s that?

HTTP browser support I guess. [Chuckles]

Yeah, if you want to use fetch you can use it or you could use other HTTP library that abstracts XHR because of the zones implementation in Angular 2 that intercepts all these asynchronous operations. It will automatically run change detection update the views; we don’t have to do scope digest that you would’ve had to do in Angular 1.

Can I ask you a question? Because this is a podcast, I’m trying to make sure that we can – the people listening can conceptualize how we’re going to use this which is what John’s initial question was which I though was awesome.

So I want to go act out an example you put out Jeff which was forms – I can still use ng-model, awesome, but I want to talk about forms for a second. So will I somehow bind to my form and do form.subscribe and then that subscribe will just send me back the ID with the value or something?

How is that going to work?

So you’ll actually – the controls in your form. I think we have something on the form itself, an observable, Rob don’t we?

Yeah, performant [inaudible].

Okay, but on the controls, each input that has a control associated with it has a property called value changes and so you’d say my input.valuechanges.subscribe and then you could subscribe to all the events from that input. But if you want to compose them together or just do any changes on the form like when the form is submitted then you would use the form’s value changes event but there are interesting ways.

Oh, okay.

Once you get the hang of observable composition then you can do some powerful things with composing the controls-observable together.

Okay, I see what you're saying. That’s actually pretty cool; I think that’s more powerful and it’s easier than the call back method, just use an ng-model.

So what I was really looking for guys is I was trying to do something with the promise where I had a service that made the HTTP call. Then basically my controller has no idea where the data is coming from. And that’s service, I cache the data or I do other things there but basically the controller, or in Angular 2 the component, basically doesn’t know anything about how it’s getting its data. Can I still so the same thing or do I have to do subscribe inside of the controller too?

Subscribe to your service? Your service can publish whatever it wants.

Right, so the service goes off and does the calls and then I’m going to go ahead and publish this, map them. But do I have to subscribe from the component to the service?

Well there’s a couple of ways you could do it. So I think you can do pretty much the way you're used to doing it today with the promise way where you're service publishes as a promise and then you .then and then you .then the results and you attach that to your controller.

So that works; in most cases, you can think about it, you can pretty much just replace the word ‘then’ with the word ‘subscribe’ and think about it the same way at the most basic level. But there’s some clever things that we can do as well with Angular 2 with this new ability to bind from the view. So all you really have to do is take your service, plug it into your controller basically and from the view say effectively subscribe to the view. So we use the asynch pipe to do that.

So if you remember in Angular 1 days, you used to be able to just assign a promise to the controller and then not have to unwrap the promise. You’ll just be able to serve this dot [inaudible] equals something that returns a promise and that is how it works now with Angular 2. We’ve got this idea of pipe and the pipe will unwrap that observable for you or unwrap that promise for you.

Is that like the asynch pipe that does like an observable pipe or something?

Yeah. Well the asynch pipe works with the observables or promises so you can mix and match them, treat them as [inaudible].

Yeah, and I guess what I’m trying to make sure and clarify is that when I’m coding this code and everybody’s coding a component, we used to have to know there was a promise to do with then, but if that [inaudible] wouldn’t care so now it sounds [inaudible] or we could use the component to subscribe or we could use pipes and [inaudible].

Yeah, you could – if you can do it the old way then you’ll have to know but if you assign it to the view or you just take that service and stick it on to the new controller then the pipe will figure it out, the asynch pipe; whether it’s observable or a promise it will pretty much handle it for you.

That’s cool. I appreciate that because I think what everybody is really wondering out there who’s thinking about this the first time is I knew I had to do it this way; tell me how I do it now with observables.

I think for a lot – in most things in Angular 2 we’re trying to maintain that ability. You knew how to do it before, it probably still works mostly the same but in most cases we’ve added this extra awesome way on top of doing that but I think that’s pretty common across the framework. There’s always this comfortable way you used to doing it and that pretty much works the same and you’ve opt in this to some of these much more powerful things if you like.

The pipes are specifically cool because it just handles both cases really nicely you didn’t have to worry about it.

Awesome.

There’s one thing – event Rob and I were talking about earlier that I want to share just as a possible scenario for reactive programming that I really like which is I often want to keep track of customers. Let’s say I want to keep track of customers and they could be changing or sorts orders – let’s say it’s orders and they could be changing but I don’t want to keep hitting the backend all the time. I want to catch them for a period of time but if it’s been too long since I last got a fresh look at the orders, I’d like it to go out and do that. Well, that’d be pretty hard to do with a promise per se.

I think we can make it easy to subscribe to a feed, an orders feed, and have that deliver fresh orders to me on a basis that the consumer doesn’t have to know about. I’m just assuming they're in my control and saying, “Hey, give me orders. And when the orders change, update it for me and you’ll know and I don’t have to care; just do it.” And I think we can arrange for that to happen with this observable-based HTTP stuff and that’s going to be a really nice feature because I want that in my app. That’s a common scenario for me.

Yeah, the difference very much between push and pull. So with a pull – if you wanted to pull your API from your controller all the time, you’ll be pulling values down and there would be a sort of observable way, it would be upstream, set up a timer and it would just push the values down the stream. It’s push versus pull is a good way to think about it. And yeah, pulling every 30 seconds, it’s two lines of code in an observable thing. At the very end of these little steps, it’s really going to get really consistent. You just subscribe at the end then whatever is triggering the changes upstream is really, really easy to handle.

Of course, time will tell.

Yup.

Time will tell.

Alright, well I’m going to be a jerk and wrap this up because we’ve been talking – by the time we’re done with picks, we’ll be over an hour. [Crosstalk]

That was too much fun.

That was fast.

Flew by.

CHUCK: Yup

Wow.

It’s a quickie, dude.

Alright, well let’s go ahead and do the picks. Jeff, do you want to start us with picks?

So I read a book recently that was pretty good and it was called Miracle Morning and it’s a book about – [crosstalk].

So good.

Getting up early. I’ve been doing it. Oh, you’ve read it, too? So I’ve been [inaudible] early and I’m a night owl and I have never woken up early. Well, it’s been really awesome so I wanted to – I’m just a few days into it but it’s been really cool so far and I hope you guys stick with it.

Yeah, I do it just about every morning and it is awesome.

What is it in a sentence? What’s the difference? What are you doing?

So the idea is that you put the other morning routine and he gives you all kinds of pointers for waking up and being more awake and things like that. But it sets your day off on the right foot and then from there you get into a routine for your day and you're used to starting it out right. So people put things in there like exercise or meditation or journaling or reading or training or – in mine, I also have things like – I have most of those things but I also have prayer and scripture studies along with my reading other books and training and watching videos and stuff like that.

No book in the world is going to get me to wake up and write a journal. It’s just not [inaudible].

You can read this one Rob. I’ll loan you my audio book copy.

What Frosty and I do which is we stay up all night and then we’re ready to have that [inaudible].

I don’t know what I’d do.

If I had kids, that’s what I’d do.

Yeah.

It’s not really an option anymore.

I don’t know why Frosty gets away with it.

[Chuckles] He could just answer his kids’ questions in his sleep.

Yeah, that’s true.

Rock star.

Alright Frosty, what are your picks?

I’m going to do a pick because we’re over time. Short book, easy ready called How We’ll Live on Mars. I read it after reading Elon Musk’s biography and it was super informative. It was like – it’s just a short book and it’s –. A scientist said, “Hey, we’re not there. We don’t know what it’s going to be like but this is likely how it’s going to be when we live on Mars.” And so he’s just going to talk about this inevitable thing that people are going to try and do and the cost and how there’ll be water. It’s super mind-opening like you end the book going, “Oh, so I guess we’re going to Mars.” And you’d start by going, “This is such rubbish. We’re not going to Mars,” and then you end the book with your mentality of, “Oh, cool. I guess we’re going to Mars.” So it’s a pretty cool, little book.

Alright. Ward, what are your picks?

I just read during those late night hours – The Phoenix Project which is a couple years old but wow was that an eye opener. It was a gripper and I can’t imagine a book about – a novel about IT being a gripper but this was because it starts out with one disaster after another and you’re wondering why the main character doesn’t quit because it’s so awful. Everything – politics is bad, the technology is bad, the people around them are fighting. It’s like ‘what are you doing in this company?’ And gradually, the guy digs his way out through the influence of some Yoda-like figure who takes you through this whole DevOps and kind of Bad Wolf world. And I found it both enjoyable and enlighten so I recommend it if you haven’t read it. And it’s cheap, too; eight bucks at Kindle.

Awesome. So I’ve got a pick; it’s kind of two picks but anyway, I’m picking RelativeFinder.org which is really cool. It backs up on to the familysearch.org database and you need an account there which is why it’s kind of two picks but it doesn’t oaf handshake things and then it connects. And there are two very cool things that it does that I just – I thought was way fun and I’ve been playing with it the last little while.

Anyway, the first thing that it does is that it tells you who you’re connected to in historical people. So for example, it tells me that I have a tenth great grandmother named Elizabeth Jackson that was involved in the Salem witch trials. Of course, further research told me that she had been tried and executed as a witch during the Salem witch trials clearly after she had had kids. I also have a twelfth great grandfather who came over on the Mayflower. This is all American History.

They do have European royalty, catholic saints and popes as well. I’m related to any number of declaration of independence signers and other famous Americans and Europeans including people like Charles Lindbergh and Amelia Earhart so it tells you that you're like sixth cousins or how many times we’re moved.

So for example, George Washington and I are fourth cousins ten times removed. Thomas Jefferson, third cousin, seven times removed. Elvis Presley is eighth cousin, one time removed or something like that. Barack Obama and I are thirteenth cousins, one time removed. [Chuckles] It’s just kind of fun. It’s like you're related to all of these interesting people. My wife is thirteenth cousins with Barack Obama so I’m actually less related to him than she is. It also turned out that my wife and I are thirteenth cousins, one time removed which means that I am as closely related to her as I am to Barack Obama.

But anyway, that’s kind of fun and that’s the other bit of it is that they have groups and if you are in the same group as somebody else then you can find out how you’re related to them. So what I did is I set up a group called Devchat because that’s where all of my podcasts live. The password is devchat, all lower case. If you go join that group then you can find out how you're related to me and anyone else in that group. So you can go check that out – relativefinder.com.

One other caveat that I want to put on this is that Family Search is run by the LDS Church so they already had my genealogy because I’m a member of the Church but it’s all free information. So if you want to use this, you actually have to put in enough information to connect with your ancestors that are already in there. And they have a huge database so it’s probably not going to be a lot of work but I’m just letting you know that if you aren’t already in there and you don’t already have an account, you may have to add your parents or your grandparents in order to get it to connect.

So you reminded me Chuck of a Rodney Dangerfield putdown.

Uh-huh.

Which is did your mom had any kids that lived?

[Chuckles] Awesome. Rob, what are your picks?

I would say that my first pick is a person – is that strange? A guy called Andre Staltz. He’s a big Reactive programming guy and I quote him all the time. He’s done a couple of really interesting things. One of them has a really good jist called The Introduction to Reactive Programming You’ve Been Missing. Google that and that’s probably by far the best explanation of how this works that I have ever seen. And he’s written a really good framework and he’s like – I’m always being a bit of a traitor here namedropping his framework, but he’s got a framework called Cycle.js.

Cycle.js is – it’s something that really helped me changed how I think about programming. So even if you're never going to use it, I think it’s a really cool framework to just try out, give a little bit of a cycle to. And it kind of distills a lot of what we have been talking about to its ultimate, purest form so it’s a really interesting project to play about so that would be my pick. Andre Staltz – google him.

Alright, well if people want to know more about Reactive programming in Angular, what should they do? Where should they go?

Send me a tweet.

Okay.

Yeah, Rob and I gave a talk at AngularConnect I think it’s called Angular Dataflow on YouTube from AngularConnect. We’re the first ten minutes or so to talk and we really simply talked about how we’re approaching it in Angular 2 so it’s a good short watch to really understand the vision.

And I just had a slightly longer version of that talk last week at Ordev in Sweden so google that as well. It’s the expanded version of our AngularConnect talk.

Yup. And finally, there were a couple of talks about this kind of stuff at Angular Remote Conf and those talks should be out here by the time this gets released.

Oh cool.

Yeah.

Yeah, that was everything that’s [inaudible] stream and that’s very much like the [inaudible] focus on that.

Yup. Alright, well thank you both for coming. We’ll go ahead and wrap the show up and we’ll catch you all next week.