Everything is a Stream - Rob Wormald

alright folks this is the last talk of the last day of angular remote comp real quick before I introduce Rob I just want to let you know that I did set up a final session I'm not going to run a video there but I did set up some questions and some polls and if you want I would really appreciate the feedback if you would take the polls and if you would go and answer the questions just leave a comment on the question if you haven't something you want to chime in with if you don't have an answer don't want to you know say anything about one of them just don't comment that's fine but it would help me in the future just figure out you know what what works for you so that said I'm gonna go ahead and turn the time over to Rob Rob works for Universal Mind where he is a Technical Architect and in his spare time spends entirely too much time on the internet talking learning and raving madly about javascript so go ahead and take it away Rob cool everybody let me just get my slide deck started up here not working okay cool so this talk is called everything as a stream I don't see slide sorry I should probably share my ok screen I see the Google hangout well there we go all right yes yep there we go cool so this talk is everything is a stream what this means will become quite clear as we go through this as usual a little bit about me and he said so I'm Rob Wormald I'm a Technical Architect at Universal Mind that means I basically get paid to fly around a country and talk to people about how to do JavaScript properly which is a pretty awesome job I'm also the author of angular sails which is an open source library for the sails j/s framework that sort of makes everything work over WebSockets so it gives you a web socket API over with the same sort of interfaces HTTP it's kind like firebase of your own sort of on your own machine I'm also a plonker addict I spend entirely too much time on on plunker kind of just clunking around if you want to sort of follow me on plunker if you like I probably have two thousand or so plunks you can't you can poke through it's a good kind of insight into my brain I hang out a lot on the angularjs and JavaScript IRC channels so if you've ever been on there I've probably spoken to you my Nick on there is Rob W you can follow me on Twitter Rob Wormald and of course my kid hub is Rob Wormald as well one of the advantages of having kind of a weird last names that I can I can grab that that Nick on basically everything so this is something you've probably heard if you're an angular developer that angular is a data driven framework and I say that probably 30 or 40 times a day when talking to people about the right way to do angular and the other thing the other thing you hear is scope events and angular are terrible right scoped out a minute and scoped out broadcasts they're in angular but there's something you should probably kind of avoid using and I think that a lot of this talk is about like how we think about events and how we think about data and so I want to mention this because it's it's it's important that like event sort of thing in JavaScript they're not going to go away but there's probably a better way to do it and this is something you'll see an angular two and we'll cover that a little bit later in the talk but I just want to mention that and then this is a quote from Victor he was kind of one of the primary architects on the the angular 2 project and it's angular 2 is a reactive framework and I just want to put this out there because what we'll cover reactive as we get into this talk but I guess the reason that I'm talking about this is that angular 2 embraces this this reactive concept as really a very very important kind of core concept to framework so this discussion that we have about angular being a data-driven framework and an events are terrible and all of these things is is to me sort of one of the biggest conflicts you deal with it as an angular developer it's it's really difficult to sort of to think about just data because the only way you can sort of affect your data is at events right and so the the thing for me is the different angular developer you find that working with data is a really nice way to think about applications it's really easy to work with data is easy to work with and the reason for that is we have all kinds of really good tools in JavaScript for working with data we have things like map right you can take an array of numbers you can iterate over it you can double these numbers and math is a really powerful concept it's really easy to use similarly we've got filter right you can you can take an array of numbers you can filter out things that you want reduce write reduce takes an array of numbers and it will do things like sum them up and again these are these are just sort of powerful core primitives and java scripts that make the language very very powerful and then in es6 this this concept goes a little bit further and so es6 is introduced the iterable and the iterator the iterator and so the iterable the iterable and iterator protocols allow us to describe anything as a collection so whereas previously we've had a we've sort of had arrays as as kind of the main collection concept in JavaScript now we've got this durable protocol and it means that we can make anything work effectively like an array like a collection and so we describe something as iterable if we can traverse its values meaning that if we can give it an API to walk over the data we can effectively pull each value out of our out of our data and work with it right so in the same way that we iterate with map or with filter or reduce we can really take any data structure in JavaScript now and and iterate over it and the way we do that is we we define an iterable protocol and we use an iterator to access those values so an example of that and this is this is one of these kind of this is not the best example of iterables but an array in JavaScript has a new method in es6 called values and what values returns to us is an iterator so you can see here that we're gonna call values on our numbers array and what we're gonna do is we're gonna call next on our iterator and what this allows us to do is lazily pull out each value from the array so you can see as I as I do this line by line you know the first one pulls out the first value second one pulls out the second value you throw a third value and then when we get to the end of the array we get a done message and so this is this is a very very powerful concept and it's not directly related to reactivity necessarily but what I want to sort of make the point of here is that this interface unifies the way that we think about collections of data and so an array is an iterable we can use maps in the same way so map is a new es6 primitive it's kind of an object key type thing and it allows us to use values and keys just like we do with objects and because a map is iterable and it has an iterator we can for example pull out the values and walk through those values so we can get the map values can call next on each one of them we can do the same thing for keys and this is something you can't really do right now with an object you have to do something like object keys turn it into an array and iterate over it so we can do the same thing with keys we can iterate get each key and do something with it and again with this iterator protocol each time we call next we get the next value until the end of the iterator and then we get this done message here same thing for entries so we can effectively walk over the tuples that is the key and the value and so we can call entries to get that and we can do next next next next and walk through that one thing you can maybe heard about in es6 is this new concept of a generator and again a generator is an iterator and an iterable actually it's both of these things but again what it means is that we can define a function here and effectively access it as if it was a collection and it means that again we call our function here our lazy numbers function we get back an iterator and we can pull again the key word here is pull each value out of the function and so this is one of these unifying concepts where you might be doing something crazy one of the demos you see here is the Fibonacci sequence right so instead of having a function that runs a huge amount of work to generate a whole bunch of you know if the Bonacci numbers we can define a generator that does this and lazily pull out each value as we need it the other thing we can do is we can make anything interval and so this is probably little bit small and maybe hard to see but this is kind of a fake custom list implementation and so JavaScript doesn't have for example things like a linked list I'm sorry a linked list and iterators an iterator protocol and the iterable protocol allows us to really again build whatever we want build a custom class a cluster a custom object and again treat it in this consistence common sort of unified API and that's that's the point of sort of the previous 10 slides here is that in es6 we have the ability to think about any data structure as an iterable thing and it means that we can always think about it in the same way it greatly unifies the way that we access our data and so this is awesome right this is this is one of the biggest things I think in JavaScript in a long time lots of other languages have it right this is not a new idea but it's it's new to JavaScript but the thing is that this doesn't really solve all of our problems the point is that this only works with synchronous values so it means that if we want to pull a value from a collection it has to be available now what that means is that it cannot be asynchronous right so generators for example and I think that one of the things when I first saw generators is that I had this thought that it's going to solve all of my asynchronous problems but actually it doesn't really do much for you in asynchronous programming right it is it is lazy that is it's not going to give you the value until you ask for it but it is not set up for asynchronous and the reason for that is that if you want to pull a value from a collection if you have to wait for it you're gonna block right the the entire application is gonna block because we know this is how JavaScript works and so that gets us into async right the thing about and I guess the way that I want you to think about a sink and sink in this in this talk is we can think about synchronous programming as pull and what I mean by that is that we can again use this iterable interface to pull values from collections right so the point there is that we as the consumer are in control I can at any point ask for a value get the next one from the collection and that happens synchronously by contrast you can think about asynchronous programming as push and what I mean by that is that if you ask for something asynchronously you sort of hand over control to the JavaScript engine and it will effectively when it's ready push that value back to you so you know promises events all of these things are push you register your interest you you set up you might ask for a value from xhr but you are really kind of at the mercy of the javascript engine to push this value back to you so a couple of examples of this right Dom events Dom events are push you you self a listener right so I'm going to add an event listener here to a button and then when somebody clicks on it Java scripts is gonna push that event to my function and then I can do something with it and the other thing about this is that once I've registered my interest in this I need to remove my interest in that right so this is kind of I just want you to remember this as the go-to talk but effectively if you're using event listeners you have to remember to clean up after yourself so effectively I say I want you to tell me when you click a button and then it's up to me as the consumer of this to clean up and and unregister my interest if you like in this event callbacks callbacks are actually events and I think we don't often think about them like this you think about them as functions and so everybody's had this problem in JavaScript right the the sort of callback pyramid of doom here and what's happening here is so though it looks like a lot of functions really what we're saying is I want to get some stuff and then when the JavaScript engine is ready right when this stuff comes back it's going to use an event to call my function and so again we're handing over control basically to the JavaScript engine each time we ask for something a synchronously and of course what the callback primitive doom you can see that my code starts to run off the side of the page and kind of lose what's over here but again the point that I want to make here is that callbacks might be functions and that's probably how we think about them but there are events that is that when the value is ready it actually is going to call the function so the cord here is an event xmlhttprequest kind of the very low-level version of how you get data is the same right so we're going to ask for some stuff we're going to register our interest so again we're going to add this event listener and that's going to be a function here and again the event fires load and then sort of we get control back and so again this is event based right and I think you're probably thinking and I think that's a lot and I think this was my initial thoughts when we got into it when I got into looking at reactive programming is that well promises have solved this problem in a lot of cases right promises give you things like fetch so fetch is a new API it's in Chrome and Firefox and instead of using that really kind of scary dirty xmlhttprequest with callbacks and events we get the the fetch API and it's promise based meaning we can ask for a value and what will happen is that when that value is ready we can register our interest and get that value out but again this is at the core of the sort of bottom level this is an event based API we don't consume it as an event but what happens again is that we've asked the jobs preventer for something we've asked the server for something and it's going to push this value back to us and the way that we get that value out of the promise is we register our interest in it right we call our nan method and when that event fires when that callback fires deep in the JavaScript engine that event fires deep in the JavaScript engine it's going to push the value to us and so promises I think are awesome right and I think that if you're an angular developer you probably use promises everywhere I think they're probably the best thing about angular today I think the probably angular was one of the frameworks that popularized promises I'll probably get yelled at for saying that but angular one really embraced the promise as kind of a core primitive so you know HTTP timeout animations all of these things in angular 1 are promise based and that's great right it makes angular an amazing framework to work with but again there's a butt here right and and the but is that promises don't solve every problem so promises are really good at things like HTTP requests but they're not good at some specific things and quite a lot of things actually so an example here this is the the geolocation API and browser and we have a watch location function here and so the watch location basically says to the browser what I want you to do is every you know 10 seconds get my my geo location coordinates get my latitude longitude and call me back and so if we use a promise here we're only gonna get the value once right because a promise will only ever result with one value and so we have this kind of mismatch in that I might want many locations I might want to continue to watch my location but a promise doesn't really handle that situation appropriately the other problem with this is that if you just let geolocation run forever it's never gonna stop right and a promise doesn't really give you a way to cancel anything right so a promise once you start it it's going to run regardless of what you do it's gonna run through to completion whether that's a success or a failure a promise is basically beyond your control right so if you fire an HTTP request anything that's promise based once it started it's gonna keep going and I think that that's sort of inherent to the design of promises and that you have this guarantee that things will complete or not will resolve or reject but introducing cancellation into that concept kind of muddies the waters and there's a lot of discussion going on with much smarter people than I about how do we cancel a promise right how do we express this idea of starting a promise and then canceling it and it gets into questions like if I cancel a promise is that a resolution or is that a rejection do I just never fire the then right like it kind of doesn't have this concept built into the idea right it's resolved or reject and cancel is really neither of those right there's a problem and I mentioned this earlier is that promises are really really good at single values right get me a list of values from my server save this to the database it's a it's a single operation but they're not really good at multiple values and again it's because this this core concept of a promise is that we'll only resolve once right so if we're using things like as I said geolocation or if you're in Cordova and you're using you know Cordova based API is that might call you back repeatedly a promise isn't really going to express that for you and so you're kind of at this point where you have to go back to using callbacks or event listeners or whatever and so the point I want to make is that from the data side right we have very much unified the way that we access data that goes back to that iterator iterable idea right we have now in es6 this consistent interface that we can use to describe how do we think about collections of data but what we don't have right now is this this sort of core unifying concept for events and for asynchronous things right so the question I want to ask you is what if we could unify all of these type things right all these event I push type api's we use the same way that we have the same unifying face for for iterables and iterators and better yet what if we could do that we could deal with multiple events multiple values multiple things you know streams of values Cordova callbacks geolocation etc what if we could clean up so what if we do have to think about unregistering event handlers an angular one right if you use a watch at some point you have to call unwatched you have to clear that watch or you get into this situation or you have really really leaky memory leaks right and so it's it's something that if there's a lot of overhead as a developer to using watch type API it's listener tape type API is because if you register your interests at some point you have to unregister your interest right and this isn't thing like I can constantly forget to do when I'm when I'm doing event type api's and it something I constantly forget to do I'm using angular's watch I always forget to unregister right like it's the scope on destroy clear up my watches unregister my event listeners etc the other thing is that going back to this way that you know promises don't let us cancel things what if we had the ability to in a consistent common clean way cancel things we don't care about so a good example of that right if you have a type a head and you're typing letters and it's doing a search for every single letter that you type in the problem with doing that promise base is that even if you don't care about the value and you wouldn't care because if you type H and then H E and then HDL you don't care about what H was you don't care about what the search was for H e but because you cannot cancel a promise there's no way to kind of dispose of that those two if you like in-flight requests right and then this is kind of the real magic of what I'm about to talk about is that it remember those tools we talked to at the beginning so map and filter and reduce and all these sort of things that you use on a day to day basis this is JavaScript promise as a job script developer what if you could use those things with events and so what if we could use those things with events and so how do we do that and I guess the point of why you're apt is talk and this is this is something that I've been working now with for for probably six months and previously I was very much like a promise guru I was an evangelist for promises I think promises are really one of the best never happened to JavaScript's but i don't think that they're they're the answer nowadays my this is one of these things that i think there's probably a lot of people out there right now they're going yeah but promises are awesome right like promises are the best thing here and what I'd really like you to do you know for the next sort of half of this talk is keep an open mind it's not a probably a good way to start but so I'm glad you asked that question right like how do you get these things and so this is the title of the talk everything is a stream and and the basic idea of this is that what this thing we're about to talk about gives us observables is a way to describe everything that we're doing in a consistent common consistent sort of unified way if you like right and so on results who is who is a guy who wrote a framework called cycle tracks he's big in the reactive community he describes reactive programming and that's what we're talking about here is programming with asynchronous data streams there's a link here at the bottom to to his probably one of the best write-ups on on reactive programming you should read this put a link to it at the end of the talk but the key that I want to mention here and these are the sort of the important words here is asynchronous data streams and this is this is the core concept of what we're about to talk about and so what's a stream right so a stream is simply a collection and again it's that collection concept we were talking about earlier arrays Maps sets generators whatever they're all collections but it's a collection that arrives over time and so if you think about a collection of the simplest collection here is an array right a stream is simply this so we have a collection and a stream arrives asynchronously one at a time and I'll do that again just just to show you right so a collection is a value it's a it's a collection of values that we have already it exists we have the whole collection a stream is exactly the same except it arrives one value at a time and so this brings us to observables observables are kind of like collections except that they arrive over time right one value at a time so you can describe what is kind of like an array but it's an array that arrives piece by piece by piece if you've worked with node you work with streams before they're very similar there's they're not exactly the same but I think that if you've worked with node strings you can kind of think about it as a as the same sort of concept right values are getting pushed over time they arrive kind of piece by piece by piece observables are also kind of like promises and that they they're the same sort of wrapper as a promise for values right so typically you would use a promise to wrap an asynchronous callback api but observables are the same idea except they work with multiple values so this is kind of the core primary difference if you like between a promise and observables that a promise will only ever resolve with one value an observable can resolve effectively with infinite values as many values as you want you can as well use an observable to resolve one value like a promise so you can use an observable exactly like you use a promise but they work with multiple values too and so if you like kind of you could think about promises as a single value observable whereas you can't really think about an observable as a single value promise and so I don't want to say that all all observer alarms sorry all promises and observables are exactly the same but they are very very similar and I think that if if this is one of these things that there's gonna be a lot of discussion about this and anger then the next six months and what I want you to remember really is that they are basically the same concept with a few differences the second thing I hear about observables is that they clean up after themselves so back to that event list or example where you add an event listener and you then have to remove it observables do that for you they clean up after themselves they they encapsulate everything and keep things nice and and it means that they prevent data leaks they prevent memory leaks they prevent you from forgetting to unregister your listeners the big thing and this is kind of one of the reasons that angular's introduced them is they can be cancelled this is something again that a promise cannot do so if you have an observable and it's spitting values at you and you don't care anymore or you're using an observable to make HTTP requests in a type-ahead if you don't care about the previous value you can dispose if you can get rid of it and this is a core thing built into the observable API and then this is the kind of super big bonus and we'll get into this is that all of those things that you can do with collections map filter reduce all these sort of really really powerful tools we have observables bring that idea to events and I think this is the thing when I when I first discovered observables that really blew my mind right and so let's talk about the observable API so the observable we're using here comes from reactive extensions there is a proposal right now to bring the observable to es7 as as a kind of core permit 'iv just like in es6 the promise became a part of the language right and so previously promises where polyfilled angular had their own there's Q there's bluebird there's RSVP the observable right now is kind of in that similar state and so we're using the observable from the reactive extensions project angular 2 uses the reactive extensions project that's actually a Microsoft project so it's it's one of these Microsoft things that's kind of in Google's world now right so typescript as well but the observable is originally kind of a Microsoft project so the API is is really quite similar to a promise and again I just want to remind you here that promises and observables very similar work very much the same in terms of how you use them and they're not really very scary here so I'll just walk through this line by line and then we'll go through some demos of how this works so an observable is created in the same way that promises by all new on the observable constructor and instead of resolve and reject which is what you're gonna promise you get this observer and so the observer is the sort of it's the the interface to the outside and so when you declare a new observable and get this observer passed in and then what you do is you call observer dot next and observer dot next allows you to in the same way that resolve spits the value out of a promise observer dot next spits the value out of the observer except that right you can notice that I'm calling this multiple times here so it allows us to call next multiple times and again push as many values as you like out of them and observable the other thing that lets us do you like a promise does is it lets us propagate errors so if something goes wrong inside of our observable you know if an HTTP request fails or anything like that we can call this error method on our observer and spit that error out and this is kind of a new concept right so if you like you can think about next as resolved and you can think about error as reject and promise terms but because it promises a single value those are the only two options right it can resolve where it can reject because an observable can spit out many values we need a way to know when the when the the observable is complete right so when we've gotten to the end of our our sequence when we've gotten our all of our requests when we've clicked all of our buttons whatever and so the observer got complete method tells the outside world that we're done right this this observer is it's done it's over or this observable is done it's over I have this slide in here twice let's get that and so the way that we consume observables right so with a promise we use dot then to get the value out with an observable we have this word subscribe and so again what I want you to look at here is that I could effectively change the word subscribe here to dot then and it would look 99% the same as we're used to you right so the first method here this is sort of beyond success functioning promise terms this is our on next function and what this does is it's called each time we get a new value the second one here is our error so if an error is called again like a promises on error in event it'll spit out the error and then we have a third function here and so this is the new thing about observables is this function is called when our observable is complete one thing to note is that observables don't necessarily have to completes but we have the option here so if we only want to show three values like we're doing here we call those three things we call complete and that way we know okay we've gotten our three values and we can then know when we're done when that when we've reached the end of that sequence this is a quick demo here on plunker because this is it's a quite a strange concept to understand without seeing what's happening here so I have that same basic bit of code here that we set up I bring up the console here for you that's so I'm gonna run this hopefully there we go and the way you'll see right so again I've created a new observable I'm calling observer dot next observer next observe about next and I am I'm registering my interest with with my subscribed callback this is my next call back and I'm logging each value registering I'm trusting errors and then obviously registering my test here and knowing when this is done and so it's really simple right and when I subscribe what I get here is one two three and I'll just run that one more time just so you can see it happen but it's tick-tick-tick and then done right very very simple stuff this is what I've been going on about for the whole sort of previous part of this talk so if you think about as I said synchronous values as pull write we can think about a sink and observables as push and what I want you to notice here is that in the same way that we can use next on a pull string to pull the next value out of the stream alright pull the next value out of the sequence excuse me pull the next value out of an array pull the next value out of a map pull the next value out of a generator as I'm doing here The Observer is kind of the dual of that the inverse of that and what this is saying is I'm pushing values out right so this is this is really the core most important thing to understand about pull versus push observable versus iterable is that we can pull on the left and we're using next to pull that is give me the next value and with an observable on the push side we are calling next to push that value out to the world and so we'll just I got a dumb at this on plunker as well so hopefully this will actually run and suck a little bit code here pretty simple stuff again so I've got my observable doing it's observable thing so I'm again creating a new observable pushing three values out of it and then completing it I'm subscribing to that I'm logging the value each time it comes out and then I'm logging when it's done same thing here with a generator right so I'm yielding a value I'm yielding a value I'm yielding a value I am getting my iterator here and I am pulling each value out of the stream so the thing I want to get across here is that they are very very similar they are mirror images and it's again it's that idea of unifying this API so we can think about it in the same way we can think about them as collections that arrive over time or collections that we pull values out and we're using really the core of this the same basic API it's this next but it's the difference between I want the next value that is I is the consumer I mean controlling that I am pulling values whereas an observable as pushing values each time you call next and Jafar Husain who's a big who's a big observable guy kind of defines this really well and it's the difference between who is in control with an iterator the consumer that is the thing that's calling all this he's in control each time he calls next the next value comes out whereas with an observable the producer is in control the observable is controlling so it's pushing values out and right that map's nicely to that idea of events and callbacks and other asynchronous things where really what's happening is values are being pushed to you so again core idea here is that they are sort of inverse mirror images duals of each other they're doing the same thing effectively have the same kind of basic interface but they're doing it in the way this would propria try to a sync versus sync I mentioned that observables can be disposed and this is a very very powerful construct so again I'm gonna create an observable here and we've all done this probably where we have an interval we want to you know do something every 100 milliseconds we want to you know make a pull request against the server we want to update it a clock whatever we use intervals for that in JavaScript the problem like many many of these things with events and sort of async things is that if we don't clean up an interval then it'll just run forever in the background and it'll pollute you know delete memory it does all kinds of nasty things and so with with said interval you get you have to have you have to remember to again clean up after yourself right and so observables have this concept built-in it's part of the core primitive API and so what we're doing here is I'm gonna just start a little counter I'm gonna create a new interval and I'm just grabbing a reference to it here and then every 100 milliseconds here I'm gonna call next and increment the value by 1 and what we've got and this is something we haven't introduced before this is a our disposal function and this allows us at any point to dispose of our observable clean it up cancel it whatever you like right and we're gonna be there is we're going to use our window dot clear enable API and clear our reference and so again we're going to take our observable gonna subscribe to it and we're gonna spit out the value each times it comes out but what I'm doing slightly different here is I'm actually obsess obsess kryb function that we're calling returns a subscriber and that subscriber gives us a way to represent if you like the connection between what's happening inside the observable and what's happening at the outside world and the subscriber provides this unsubscribe method and so if we call unsubscribe here it's going to call our disposal function here and so again if we call subscribe or unsubscribe it's going to call whatever we returned is our disposal function and in this case it's gonna clear our interval it's gonna stop our ticks right and so we'll show this I gotta plug this and so again same basic idea we're creating a new observable because their account keep a reference towards interval every 500 milliseconds we're going to push the next value out we're going to spit the next number out and then we've got our disposal function here where we're gonna clear our interval so I'm gonna subscribe I'm gonna log the value each times it comes out and then I'm gonna know what it's done and so what I've got here is I've got our our unsubscribed set up to happen after five seconds so instead of this function running forever when I run it what'll happen is you'll see it'll start to spit out values every 500 milliseconds right 1 2 3 4 5 but after a time it stops and this is something that enables some very very powerful things that we'll talk about later but again the key here is that it allows us to clean up dispose stop what's happening internally and this is that kind of primary difference between a promise and observable is that a promise you don't really have any control of what's happening inside of the promise right you have no way to access what's happening internally there are some hacky ways to do it but all of them kind of break the basic concept of a promise an observable again has this idea built in from the very beginning so we talked about events and sort of push events here and so this is kind of the this is the sort of hello world of absorb wholes if you like so I have a demo of this and this is something that angular 2 does and we'll get into that a little bit later but I just want to show you here that so we've talked about you know an interval is a very simple thing to work at but Dom events are beautifully expressed as observables so what I'm gonna do here is to come up what I've got is a server got is a button on my view here I'm getting a reference to it I'm creating a new observable and I'm saying each time I click the button call observer about next I'm registering that event listener here and then again I've got this disposal function that is remove an event listener so it allows us to register our interest in these click events add an event listener cleanup map for the facts and what you'll see this is really simple right so I've got my SUBSCRIBE function here I'm just gonna log each time I click the button and you'll see that it starts to spit out Mouse events and as I click it but notice that if I don't do anything nothing happens right so again I as the producer of these clicks I'm in control each time I click an event comes out and abettin comes out and I think at first glance this is kind of underwhelming right you sort of go okay great like I can do this manually there's not a whole lot to this but we're just gets very powerful and this is where things get interesting I think so you've created a first observable here you know how to do that Rx has a little built-in for this I think this is my next demo but observable has some sort of utility functions so instead of having to do all that like manual wrap my click event manually wrap my button I have a shortcut method I can just say give me an observable from an event on a thing that produces events and I'm gonna listen to the click events so again it's the same as what we just did here but in one line of code one thing I wanna mention here because I'm gonna do this in the rest of these examples is that I'm using this dollar sign at the end of the name of my variable this isn't anything really specific to observables but it's it's a convention that you kind of see in reactive land and it's it's designed to allow you to see the difference between a normal collection a normal array right so we could I don't push clicks into it into an array but this dollar sign sort of delineates that it's an observable it's a stream as opposed to a vanilla collection right so the other thing we can do right so again if you can listen to a button you can listen to anything that comes off the Dom here and this is something that I think this is real sort of interesting right so I have an input this is this and what I'm gonna do is I'm gonna say give me a stream of events each time I key up right so each time I push the button and I let go of it or I just time I type a letter and let go of it I want you to give me a stream of that and so again this is our shortcut method from the observable thing and then what I'm gonna do and this is this is where I get super super interesting is that I'm gonna take this stream and again if we can think of a stream like an array that we can do things with right it's an array that arrives over time I can use map and this is where it gets awesome right so I can say map and instead of getting the entire click event all I really care about when I'm typing in here is the letters that are coming out right so I'm just gonna say map just like you'd map Bourbon array and all I want is the event target value and that's what kind of that's just gonna pull out if you like the letters that are in there so if I now start typing you will see that each time I hit a key it's going to push a value into my key upstream and then my key ups are being mapped transformed into just the values right so this is very very simple and then of course we're gonna subscribe to that and each time we get a value out it's going to spit it out so key thing here this is an operator it works just like array dot map except that we were doing this over Dom events right this is not an array of click events this is a stream of values but we can treat it operate on it exactly like it's an array of events that's like a little bit further right so this is a sort of slightly more interesting demo this is our reduced right so we've got a reduced function in JavaScript observables or rx at least calls that scan scan and reduce or kind of effectively the same thing we won't get too much into the details here but again what I'm gonna do here is I'm gonna grab a reference to two buttons I'm going to do that thing where I'm going to map and what I'm gonna do is take the value when I parse it into an integer and I'm going to basically take my event string here so this is my clicks from my incurred button and this is my clicks from my decrement button so I've got two streams I'm then gonna use this neat operator called merge and what that's gonna do is take my stream of button clicks coming from my first button and my stream of button clicks coming from my second button and it's gonna merge them into a single stream and then what I'm gonna do for each of the values that comes through that stream I'm gonna map it and use my get value function here so again what we're gonna get is a stream of Dom events a stream of clicks click events if you like and then all I'm gonna do is pull out the number that's assigned to them and then I'm gonna use my scan function here to do effectively or reduce right so you've done we showed a little bit earlier I did that sum of numbers right this is the same idea so this is a demo that's kind of easier to see than explain so again I've got a button here which is an increment button with a value of 1 I've got a button here with a decrement ID and a value of negative 1 and then I've got will output box here and what you'll see is as I click the button here it goes up and as I click the button it goes down right so the code for this again pretty simple grab a button grab a button grab the output increments so that's my stream of clicks from this button here this is decrement this is my stream of clicks on this button here I'm going to merge them together and I'm going to map and just get the the number so what I'm doing there right is I've got value 1 and value negative 1 and so I'm taking my stream of click events and I'm transforming that mapping that in to effectively a stream of numbers I don't know what I'll just show you that manually here so we can kind of see what that looks like so if I do a changes stop subscribe any luck as I click here right so if I click 1 1 1 1 1 negative 1 negative law unnavigable so you're saying as I'm getting a stream of the numbers I've transformed I've transformed my click events into numbers take this back what I'm doing here and this is this is quite an interesting concept I think is that I'm scanning and again just think of scan is reduced except that it's happening sort of in real time so I'm getting the previous value and then this is the value that's coming in from my click stream and I'm just taking the total this value here and I'm adding it starting with zero right so each time I click the button one or negative one it's going to add that to the total and then basically what I get is a running total clicks right so I can count out I can count down right very very simple but very very powerful when you start composing these things so here's some good news and some bad news the bad news first right so everybody who's used angular 1 is very used to using promises so dollar sign HTTP returns promises big news you may not know this if you haven't used angular twos HTTP is that angular twos HTTP returns observables there's a lot of discussion about this when angular 2 is being planned if you google around on the web you can you can find these discussions and I think that the angular 2 team made a decision that realizing all the things we've talked about here promises worked fine for HTTP but if you've tried to do some very specific things in angular 2 or in angular 1 with promises you'll find that it doesn't always work out I'm gonna make some things very very very complicated so I have a demo of what's happening here a little bit later but I want to show you kind of just step by step what's the idea is of why we want to do this why we want to use observables for HTTP instead of promises so I'm gonna do and this is effectively this is a type-ahead if you like kind of basic demo so I've got a button and I'm doing like I've been doing in the previous slides here is I've got a stream of key ups I'm gonna map those key ups I'm gonna change them to just the value right so I've got it boxing's time i type in it it's gonna give me the letter and I'm gonna introduce this new operator called flat map flatmap s-- a little bit difficult to explain without sort of playing with it but what flat map does is it's it's a little bit like promise dot all in that if you give it a an asynchronous value and so in this case we're gonna what we're gonna do is we're going to take our inputs so what's happening here is I'm typing in an input box and each time I lift the key I'm gonna get a letter and I'm gonna make an HTTP request with that letter so I'm doing like a search against a fake server here right so what I'm doing is mapping each value that's coming out of my text dream into an HTTP request so in the same way if you had an array of IDs and you wanted to promise to all you would map over them you would turn them into HTTP requests and then you would promise that all and wait for them flat maps very similar except that we don't have to wait for all of them right each time a new value comes in it will do it's asynchronous thing and in this case that's making an HTTP request and then it will when the response completes it will spit the next value downstream so what I'm doing right I've got it responses which is a array of inputs flat mapped into an array of requests I'm starting into a stream of requests and then for each of those requests that's coming down I'm going to just get the JSON out of it and so what you end up with is this response to stop subscribe and I'm gonna log effectively the responses each time they come out right so it's name name name I have a demo a little bit later but I just want to show you this kind of basic flat map concept right we talked earlier that a promise could not be canceled so this is the exact same code as previously here but instead of using flat map here I'm using flat map latest flat map elite latest is really really interesting and this is I think this is one of these things that this is where you start to see the real benefits of using observables over so let's imagine that I'm typing in an input box right and I'm gonna type very very quickly here each time I click or you time I let go of the key it's gonna fire an HTTP request right think of this as an autocomplete or type-ahead the point is is that if i've started a request and then I immediately type another letter I don't care about the request that's in-flight anymore right like it's no longer valid it's not the current value and so what flatmap latest does is exactly the same as flat knob except that if a new value comes in while that request is still in process right it's gonna cancel the previous request it's gonna dispose of it it's gonna forget about it and in terms of HTTP is actually gonna cancel the underlying request this is great if you're on mobile if you're on a slow connection if you're on you know limited data scenario because with a promise if you fire a request it's gonna complete even if you don't listen for the value it's still gonna complete with an observable based API and so HTTP is an observable based API it's actually not gonna complete the request it's gonna cancel it under the hood it's like you see it in the console actually being cancelled so again inputs coming in flat maps being flat mapped into HTTP requests waiting for that response and spitting out the responses except that if a new value comes down the string before the previous one has completed it's gonna cancel the previous one and only pass through the latest value so the other thing about angular 2 in addition to the HTTP API being being observable based the form builder that is the the model-based forms if used angular 2 at all you've probably played with model-based forms so model-based forms are observable as well and this is that same idea as as that I've been doing sort of doing the attach an event listener to an input and then map values and then only spit the values downstream the form builder API the model-based forms in angular actually kind of sugar is all about for I mean it gives me effectively a stream of value changes so this is a search form and I've got a list of controls that's my name here so what I'm saying is I only care about when the name value changes and then each time that value changes flatmap that into an HTTP request and then map that into res days on but this I think is probably one of the coolest things about angular 2 what you'll notice here is that I'm not actually calling subscribe on my stream right so and all the previous API as I've been calling I'll show you here I've been calling subscribe right and subscribe is the way that I get values out of a stream angular 2 because it has this idea built in because it's built into the core of angular I can actually just tell the view to subscribe for me and so what I'm doing here is I've got a people stream here right and so this is actually a observable attached directly to my controller and what to my components and I'm doing in the view as I'm iterating over that observable and I'm using the async pipe to do that the best way to explain this is if you if you used angular in its early days so angular 1.1 and go to 1.2 you used to be able to basically assign a promise directly to the view and angular would unwrap it for you and that was really handy because you didn't have to call then in your controller right you could just do scope dot people equals HTTP get some people anchors who sort of reintroduces this concept but in a really really clever way there's a couple of things about this number one this works with promises or observables so each time a new value comes down the stream it's gonna update the view the other thing and this is again one of these things that at the very beginning of this presentation I said that angular2 as a reactive system because angular2 has this kind of core concept built into the whole framework when I use the async pipe I actually have the option to turn off change detection in angular and what that means is that instead of angular constantly checking whether or not anything is updated because I have an observable that's pushing values into the view right my observable can actually tell angular that something has changed and that's incredibly powerful because it gives us a massive efficiency boost so instead of thing you are constantly checking you know up again angular sort of pulling values if you like with an observable based system angular is actually being pushed values from our data right so our data is telling angular something has changed update the view I have a little demo of this if you follow me on Twitter you've probably seen this and so this is like a little youtube search right so again I'm just gonna type I don't know if it cats now what I get is a I'm gonna have a stream of letters going into this which is being turned into a stream of values I'll show you the code for this and so this is a really simple sort of angular 2 components and what I'm doing down here is I have my query box so this is my form itself so you can see that's a youtube career here it matches up with a youtube query here I've got the title here and that matches up with my input box here and what I'm getting then is effectively a stream of queries coming off with my video right so each time the value is changing I have a new text value coming into a stream and then what I'm doing is taking that stream of queries and I'm flat mapping it into a youtube request so this is this is a simple I'll show you this here this is a very simple service and in a go one terms right and I'm doing an HTTP requests adding some data to it this 2rx this is a kind of a legacy thing that's disappearing quite quickly this is just a kind of underlying printed in the angular API you can ignore this it's going away so again a new value comes into my query it's gonna return instead of returning a promise like it would an angular one what I'm returning is an observable of HTTP requests that's been mapped into JSON and then because the YouTube API sort of returns this wrapped this wrapped object I'm only pulling out the items so with a promise based API this would look something like this HTTP GET Ren Ren with an observable we use kind of the more appropriate term which to me is map right like then sort of obfuscation what's actually happening right it is a map we are transforming each value as it comes to the stream so this is up on plunker you can have a look at it and I'll switch back over here so gonna the key thing I want you to get here is that this is effectively fully reactive would be determined with you this right so I have a stream of values coming out of the view I am mapping that into a stream of requests which gets mapped into a stream of responses and then I'm really just mapping that at a JSON and connecting it to the view so the if you like the controller is reacting to the view it's changing some data it's doing something and then the view is reacting to that stream that's coming back and this is where that term of reactive programming is coming right so at no point am i calling like subscribe do a thing or like then do a thing it's it's very much the whole thing is just a cycle right a new value comes in it gets into an HTTP request that HTTP request gets changed into response and that response then gets subscribed to by the view so that the stream of people is pushing datas our data into the view and again because we can turn off change detection here things get ridiculously fast and ridiculously powerful so that's a big deal it's kind of it's a lot to explain and a talk but I think that as you start to play with angular 2 you'll see this concept a lot more another reason that that HTTP so like what we did here was very cool I think it's an interesting way of doing things and it's very powerful but it doesn't kind of give you the full story so retries right if you've ever tried to do a retry with a promise you can do it it's kind of a sort of a convoluted thing where you have to do then and then check and see if it's actually you know completed or not if there's an error or not and it's so kind of redo your promise and because a promise only resolves once right it's quite difficult to sort of fire a request again observables have this concept built in so again this is my I'm gonna use the angular 2 service here I'm gonna get a bad connection right so if I'm on mobile and it's kind of a slow connection or if I'm on a really crappy 3G connection built into the observable option is this idea of retry and so what this says is that if my request fails instead of spitting an error out downstream right like a promise would I want you to retry it three times before that happens and so this allows you to is literally in one line of code and this is not kind of this is not me making anything up this is not something that's kind of obfuscated away this is built into the into the reactive extensions API retry simply retries the previous stream three times and if it doesn't work in three times then it will eventually propagate the error to us but this is massive for mobile apps for things that aren't poor connections for you know servers that might be overloaded if you're not really if you've got a server that's being hammered by millions of people you can throw this retry in and it'll sort of trance apparently retry everything for you and it means you don't to do any special handling you just throw this in and and I I have started kind of throwing this into every single request that I have because it allows you to very very quickly do a retry and nobody downstream has to worry about it nobody downstream has any idea that this has happening um so that's a really big thing and it's like it's one of these really nice things you'll get from the new HTTP and angular so maybe like we talked a lot about polling right and angular if you want to pull an API the RX the RX api gives us this inter things so this is equivalent to that demo I did near the beginning where I was setting an interval and you know clearing the interval our ex has this built in so this is a really nice little sugar and effectively what I'm gonna get here is every 5 seconds I'm gonna get a tape right it's gonna send a new value downstream and so I'm gonna then take each tick right every 5 seconds and again at any value I'm gonna change that tick into an HTTP request to get some stocks right and then I'm gonna map that into the responses again because we're using this consistent common API like what I want to stop pulling what I want to stop listening I've got this stock puller and I can just unsubscribe from it and that will again cancel the request okay so the interval will cancel everything that's happening sort of upstream from there right so again it's it's a it's a really kind of simple change to go from HTTP or from the promises to observables but it adds all kinds of incredibly powerful functionality that's really a lot more verbose and a lot more difficult to reason about with promises and in some cases it's almost impossible to actually do with promises and so for example one of the things I'm using that flatmap latest operator I used earlier so if my HTTP request takes longer than the interval instead of stacking up right instead of sort of waiting five seconds and then getting to value spit downstream after one up to the other it's just gonna cancel the previous request and fire off anyone so again it's one line of code and it gives us some things that are very difficult to express with promises now this is kind of a final slide of this and this is something that's a little bit difficult to explain but I want to show it to you because it's I think it's a it's an incredibly powerful cool thing over in react land and so not a reactive react j/s lands there's a new data library called redux and Redux is based on this idea of reduce right so again we've been talking about reducers a little bit here Redux is a way to effectively manage all of your applications States in a very very clean very very powerful and immutable way and so I'm not gonna run through this law in my line because I'm gonna show you in the demo but I want you to notice that this is a function and what it is is a reducer function so it's the same as we did in the counter example where I had you know values coming in and then a previous value if you like or if you want to think about it like this that counter this state was the total right so we would sort of describe state as the state of your data the state of your application state is the the total if you like and then the action is what I want to change and so we just time I get an action in here so again if this is connected to a stream of actions that is a stream of things that I want to change in the application each time I get an action it's gonna call this reduce function I'm gonna do something so if you've used react at all this should look familiar this is kind of the flux flux standard action so if I call an add to do action I'm gonna add a new to do to it if I call remove I'm gonna filter out what to do and only return the two dues that don't match if I'm gonna update it to do I'm gonna basically update the one to do and then return the state and what I'm doing is I'm changing my data so effectively this is I'm changing my list of to dues in the application and then I'm returning a new one and so this this basically unifies everything about my applications data state I'm not gonna babble about this because it's kind of difficult to see but I think this is quite a cool demo and I tweeted this if you follow me on Twitter you've probably seen this so this is an angular 2 based and to do mbc demo but there's a couple cool things about it so like this is like give a talk and i am i can do things like check them off i can only show my active ones or only show completed ones i don't know why that's things in spanish but it's not so this is like you know your basic to NBC demo here the thing that i want to show you in the code and this link is will be in the slides and all i'll tweet this out again this is a fully reactive angular application so there is effectively no dirty checking whatsoever in this application and what i'm doing here and this is kind of the easiest way to see this is I have in my location components I have a stream and observable of all the to do's in the application right and so every time I change it to you every time I call that reducer function we looked at I'm gonna get a new list of to do's down the pipe angular's not gonna dirty check it it's not polling it's not doing any of these things it's my application is telling angular this is what has changed so like if you look at if I want to update it to do or if I want to market to do is completed what I'm doing in and this is a very much a react kind of paradigms I'm dispatching an action and when I dispatched an action here it's going to affect the state and that reducer and it's going to again because this is going up to that kind of course store it's gonna fire another value into this this stream and it means the application is kind of instead of watching the application is being told hey here's a new value right so that's probably I guess it's probably the end of my talk I think I'm slightly over here and we'll just check my slides yeah so the thing that I want again this is the talk topic of the topic or the title of the topic everything is a stream and I want you to think and I'm happy to talk to anybody about this because as you can tell I'm probably a little bit excited about this everything in your application beings can be expressed this way button clicks HTTP requests views data changes whatever and if you can think of everything as a stream then it makes your application a more performance and be way easier to reason about right like you don't have mutation you don't have event handlers all the place you'll have to clean up watches you don't have to cook there's so much you don't have to do and the idea of treating everything as a stream is it allows you to do angular applications in a way that is way way more awesome than the way we do ain't go run applications I got lists of resources here you should read if you have any trust in this andres Tulsa's introduction to reactive programming check out the reactive extensions api arts models is a really useful kind of tool for understanding what I've been talking about the past hour and then egghead has a bunch of new rxjs videos done by some really awesome rxjs people so it's worth watching those as well so yeah I think that's probably the end and any questions I haven't run over my time too much you are about 10 minutes overtime but I'll ask questions anyway really really interesting I the top question is can we get links to the slides and demos yes I will pop this out on Twitter if you follow me on Twitter okay and I'll see if I get them into the community as well all right next question this one's from Jeff Whelpley he asked it before the the talk even started he said I Ron I heared all right here I heared I heared immutable J s is what all the cool kids are using why would I want to use observables so they're not necessarily kind of it's not really a one or the other sort of decision I think if you read victor savkin post on that quote that I said which is about angular 2 being a reactive system there are appropriate use cases for both I think that immutable is a really good way to represent data state and actually that little to do NBC demo I showed there would have been a lot simpler if I've been using immutable but the point is that immutable is kind of the way that you represent data and rx or reactive stuff is kind of how you react to those that data changing right so you could quite happily use immutable inside of rx the thing is that because this is all sort of immutable by default right like map and filter and reduce are all immutable anyway right there's not a huge use case necessarily for using immutable J's because the fact of it being a stream we're all values are kind of going down the pipe anyway the whole thing is sort of immutable by default which is really nice but no they're not necessarily it's not necessarily one of the other choice interesting Liang go-to because the the the observable allows you to kind of tell angular that things are changing it can be significantly more performant in angle to if you're using observables over immutable immutable gives you a boost but observable is by far the fastest way to make angler - that's very nice okay then question is is it possible to turn observable on after disposing so yeah an observable can be really cool things about it right and that's actually how the the retry in HTTP works right so you can re subscribe to an observable and it will basically just restart as normal and again that's not something you can do the promise so yeah absolutely and that's how as I said retry and a lot of these these interesting operators work that way they're they're sort of Reese absque writing under the hood right follow-up question is on the ones that kind of had the internal state like an increment decrement and all that stuff does it maintain the state if it's not explicitly cleared by your disposing function does it maintain a stay so you know if I were to unsubscribe no it would not actually that's a good question I would actually I don't believe so though so if everything unsubscribe from it it would reset a zero essentially well then so that's that's interesting right like the an rx observable like I've kind of showed the simplest version of this the rx API if you look - it has some some like 40 different operators and they deal with things like this so you can have observables that will automatically unsubscribe if know things are subscribed to anymore you can have observables that stasis stay active hot forever I guess the short answer that is that if you want to do that there is almost certainly a way to do it and that's actually really good question so some if whoever asked that wants to ping me on Twitter I would love to kind of experiment that and give you a better answer that question okay the next question is how are multiple subscribers handled what if a subscriber well they're they're like three questions here so how are multiple subscribers handled so kind of by default a subscriber I'm sorry a observable Tilly has one subscriber now what's interesting is if you take like if you had an array of I don't know if you had a stream of things coming down the pipe and you filtered that into another stream right and that's that's the important thing to realize it every time you add an operator every time you do an operator to it you get another observable right so you could take like you know I don't know foods and bars and filter out the foods and subscribe to that and filter out the bars and subscribe to that as well you can there are some again there's some operators in rx things like Connect and publish that allow you to effectively make an observable multi subscribe wool or wool if you like right the thing with that it's obvious you can do that then you have to be a little bit more aware about unsubscribing to the way those things work right but yeah again like there's a way to do it in Rx for almost any sort situation they like so if you want to subscribe multiple subscribers you have to do a little bit more yeah there's like this one more operator it's like publish is basically what it is narcs right now I don't know it is in the new Rx and then you can do like published and subscribe and then there's published and ref count which will allow you to subscribe subscribe subscribe and as people unsubscribe when you get to zero it will dispose of the observable okay and what if a subscriber comes in late doesn't start from the beginning I guess is what they're wondering or does it just kind of pick up or everything else is getting its stream from sure and so this is something that I didn't cover and she's like I went ten minutes over without covering this but observables kind of come in two flavors there is the idea what's called a cold observable and I probably should have mentioned this that if we go back to our HTTP demo they're like if you don't call subscribe unobservable nothing happens they're lazy whereas like a promise if you call HTTP of get in angular right now it'll fire off that request immediately if you call HTTP I'll get in the new angular 2 HTTP nothing that happens right it's it's lazy and so if you subscribe to that that's what kicks off the process right so hot and cold observables I will talk with women if I start talking about this I posted some links to the egghead videos on there and undressed altas are really or been or Andre has a really good little like two minute egghead video on hot versus cold but again there are there are ways to do it so if you haven't observable and you subscribe to it and it's kind of doing its thing if somebody subscribes later to that by default they'll kind of get what's coming down the pipe at the current time right there's the ability to sort of say I think it's called a replay subject is the operator that allows you to sort of memo eyes and sort of like keep a cache of the last value over the last two values or whatever pretty much all of these kind of scenarios are very much covered by the it's API nice the the last part of this question is what if a new subscriber comes in after the last previous subscribe subscriber has unsubscribed so at that point it would be it like a new observable right so whatever is happening in the guts of that like so if you haven't had an interval and you tick tick tick tick tick and then you go I'm subscribed and that would sort of be disposed and then Yuri subscribe that would then start ticking at you know zero zero account over cool what are the best resources to continue learning about observables so the activity is really good the I posted on that last slide and I'll tweet that out in just a second here Rx Marbles is really good in terms of like understanding how these operators work how these things flow together the reactive extensions website and so one thing I want to mention is that reactive extensions is not just a JavaScript project like this is I think it came from dotnet event originally on maybe c-sharp but they're there like there's no reactive extensions for like twelve different languages so you can this isn't Java you can do this in Objective C Swift you can like this everywhere right and so they're the kind of core concepts of all this are really well documented on the reactive extensions website certainly like if you if you have any questions about this I'm totally stoked to answer questions so you know send me tweet or whatever if you have a specific question send me a plunk I'll just plug like a few other people have angular buddies calm that's our slash channel join that and we have an Rx channel and I'm always in there evangelizing about this so definitely pop in and asking questions in there okay next question can you set up automatic options for HTTP in angular 2 for example I'd love to make all of my requests retry a few times and then override where I need to sure so this is an interesting question and there's a there's an issue on the angular 2 github right now talking about like how we think about you know any other one we have interceptors and you have transformers and kind of these these core things and one of the big things that is not very nice about interceptors and transformers is that they you know the sort of global and debate the problem is if you have a big angular application you have different you know different things doing different parts especially if you are going to big team of people there's only this kind of core HTTP service rights to singleton and it means that if you change an interceptor in one place it can change it kind of unexpectedly for somebody else so one of the things we're kind of talking about right now and kind of there's no there's an open issue like I would love your comments on it because I'm rewriting all this stuff at the moment is that we think that the way to do this is probably going to be composition and what I mean by that is in the same way that right now in angular any other one you really wouldn't inject like dollar sign HTTP into your controller you have a service that managed that for you right the sort of right way to do it we think in in angular 2 is going to be have a service that wraps it right this is composition and you saw me kind of composing these things together in the same way you can compose map and filter all of that so you'd likely have like a my API service right you would just do a retry in there and just return that so we're trying to get away from this idea of kind of mutable global States in all of the aberration right but yeah I think that like the right way to that probably would be to to basically sort of wrap it in your in a composed service return them but do post that on the angular thread I definitely would be open to comments right now because we want to cover all these these cases and a lot of them like we thought about some of them but some of them you know interesting questions like that are really good so we'll give them a bit more thoughts the API for that yeah a related question is you know then is it possible to configure integrals and retrying like incremental enrolls yeah there's I believe there's like an operator for like retry when and I think this one's like a reach right on yeah like again there's yes almost certainly and if not what is it one of the cool things about our X is that if you want to do something like that right like adding your own operators and I guess I should veg and I keep saying operators and those are like Matt filter reviews all these things are operators right the new rx has a really simple facility for adding your own operators so you just like throw a new operator on there to do something really custom and special and again everything else downstream will just see it as a regular stream of values yeah you could do like exponential back-off you know there's all kinds of cool stuff you could do with that all right last question do you know anything about upcoming features in our X dot are next do I know anything about upcoming features narcs next I think I mean as far as I know I think the API on that is is kind of relatively getting stable there's a ton of operators yet to be implemented I think the current version orx has something like 50 maybe and I think probably rx NEX right now has like 20 or 25 so there's some open issues in there like about the operators to add but I think more or less that the API is pretty much stable and I don't think they really want to like add too much new stuff to it you know that I think the key thing is going to be ok now we just add operators no answer appropriate if that didn't answer that that person question then again just send me tweet whatever be happy to answer happy answer all right that's all the questions thank you again for coming and talking to us Rob and sorry for going overtime on that no it's good I mean I asked when you hit your time and everyone was like yeah I'll let it keep going because we love it so cool and no problem here every everybody gets extra extra bonus content I guess so so yeah so thank you very much I'm gonna go ahead and work on putting the you know all the information up on the community forum and anything else so if you have any requests questions or anything like that you know feel free to put those in the community forum and we'll get that in as soon as possible well and then the last thing is is after this is over I'm gonna pull everybody over to the feedback session the feedback session is where you can give me some feedback I've got some questions and some polls they're obviously we're not gonna answer those questions in a session but if you want to leave an answer in the comments I'd appreciate that and then the polls just help me know okay how do people want to get what we're giving out here so I would appreciate that finally if you want to go check out the feedback session there is a little I called it an Easter Egg but basically it's a discount code for Jace Ermakov the site is now up that code is good for two weeks so you know go go ahead and get signed up if you're excited for that it's going to be January 14th through 16th I'm also doing a rails remote comic that's your thing that's gonna be November 5th through 7th and you can go sign up for that a trails remote camp calm I have not set up that coupon code for that but anyway go ahead and go sign up for that as well and I really appreciate everybody coming so yeah that's all I've got so I'm gonna go ahead and end this session thank you again Rob and we will look forward to talking again at the next conference you attend indeed

Channel: Devchat.tv

Views: 17,759

Rating: 4.9666667 out of 5

Keywords: AngularJS (Software), Software (Industry), Software Development (Industry), #hangoutsonair, Hangouts On Air, #hoa

Id: UHI0AzD_WfY

Length: 85min 1sec (5101 seconds)

Published: Wed Dec 09 2015