Reactive Sequences

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kyle Simpson: I did say that RxJS is pretty well standardized it's a it's a really good idea. It's probably a pretty good sense of what we're going to end up with or something very close to it. If we get observables in JavaScript. I've tried a number of times to learn RxJS honestly I have.

[00:00:25]
I've never had enough time to get through all of that documentation the training courses I've gone through. It takes a lot of effort and, comparatively speaking, if I try to analyze the asynchronous event based coding that I do in my programs, there's actually kind of a small subset of things that I really do on a common basis.

[00:00:47]
So it occurred to me that if I'm already pretty familiar with using asynquence for my generators and my promises, why not have reactive programming capabilities with an asynquence. That actually fits pretty well ,because I'm already dealing with sequences. That's my abstraction, so all I need to do is be able to make repeatable sequences.

[00:01:06]
And then it fits right in with the same abstractions that have already created and all the same methods and utilities that I've got, they all work on reactive as well. So what I did was add reactive sequences to the library. For our purposes, rather than me trying to get you bogged down into learning all the complexities of RxJS, I'm gonna show you reactive sequences which work very, very similarly to the RxJS observables.

[00:01:32]
And I'm actually gonna show you that you can transparently go between the two. So, you can take in a reactive sequence and make an RxJS observable and vice versa if you need to. But this is just like, it's like the five or six most common ones you need put down and inside of a tiny little implementation.

[00:01:52]
So instead of having to bring in a 200k library, you get this for like 3k in asynquence. So that's really all it is trying to make it a little little easier to wrap your brain around. So I can make a utility like fromEvent which looks exactly like the one provided by the observables that takes an done element takes an event name and it attaches and here I'm using JQuery just to save room on the slides of course we don't use JQuery.

[00:02:21]
[COUGH] So from a vent utility is how I make an observable and you see I do that on line 8. Now I'm gonna call mine I use the term reactive sequence instead of observable I did that on purpose. Because it's not an observable it's isomorphic with observables they can go back and forth.

[00:02:42]
But it's not an observable it's my own little thing it's a much smaller simpler thing so rather than calling it an observable and having people complain that it doesn't do exactly the same thing that our RxJS observables do. It's a reactive sequence, but it's transparently very similar. So you can go back and forth.

[00:03:00]
So I'm going to call it rsq, just to keep things clear, it's a reactive sequence. And then you'll notice I just start chaining off of it exactly like I do any other asynquence. Used .vals and .thens and .seqs. I can use .runners, I can use any of the abstractions provided to me by the asynchronous library directly off of a reactive sequence.

[00:03:25]
And under the covers the reactive sequence takes care of repeating all those steps every time a new piece of data flows through, so you don't have to worry about that whole repeating thing. It figures out how to repeat the chain over, and over, and over again. You could sort of think about a reactive sequences like a sequence template.

[00:03:44]
You declare what the sequence template looks like an asynquence will repeat, it will clone and repeat that template every time it needs to. So that's a pretty lightweight way of getting started playing with observables you don't need some big library. You just take knowledge that you already have, a little bit of a knowledge about asynquence, and hook it up.

[00:04:07]
And the main thing, as you can see up there on line 2, the main way we create a reactive sequence is to say ASQ.react. And that gives us a function, which I call proceed. And every time that thing is called, whatever you pass to it is data that gets pumped down the chain.

[00:04:23]
It's really pretty straightforward. I want to point out an alternate implementation of that from event to show you a different way of thinking about a reactive sequence. Here, I make an empty reactive sequence by just saying ASQ.react.of with no data in it that's exactly the same syntax as RxJS uses.

[00:04:47]
They have a .of method that you can pass nothing into it or pass data into it so it's exactly the same thing. But you notice that I have a push method that I'm referencing on line 3. So you can manually pump data into your reactive sequences which is what I'm doing here.

[00:05:05]
I'm making the event binding manually pump data and it's gonna accomplish exactly the same thing as the code on the other side but it shows you the reactive sequences are things that you can pump data into if you want to. I actually end up using that quite a bit.

[00:05:27]
So here's a quick example. I make an empty sequence up on line 1 called rsq1, and I make another one called rsq2, which I preset some data in, I pre-pumped some data in three pieces of data, three numbers, 1, 2, 3. And then I set myself up with an interval.

[00:05:44]
So I'm just going to, every 500 milliseconds push some more data down that stream. Each one of those streams, I'm gonna push some numbers down. So those are starting out at 10 and 11 there on line 6 and 7, the values 10 and 11 as they increment. Elsewhere in my program I'm going to subscribe to those two observables those two reactive sequences.

[00:06:04]
Line ten I subscribe to rsq1 and I print out whatever I'm getting there and you notice if you follow the flow there because rsq1 didn't have any data the first piece of data gets down the stream is the value ten. And then 500 milliseconds later, it gets the value 12, and then the value 14.

[00:06:20]
What about rsq2 it already had three pieces of data in the stream. So the 1, 2 and 3 are gonna come out right away as we see on line 18. And then we're gonna start every 500 milliseconds getting the values 11, 13, 15 and so forth. So these are just streams we can pump data into them and get data out on the other end that's all.

[00:06:40]
That's all it takes to understand what's happening here.
>> Kyle Simpson: Because these are just streams, we can define higher level operations, the stream operations. This is maybe the most important thing that I'm going to teach you about all of reactive programming. This is what really unlocks the magic of reactive programming.

[00:07:07]
If you think about them as streams, we can define certain operations for composing streams together. So here I have two different streams, I have an rsq1 and rsq2. They're both coming from different DOM events. One of them is clicks on a button and one of them is key presses in an input box, okay?

[00:07:23]
We could individually subscribe to those and be notified when any one of those events happen. But what if I wanted to listen to a sort of synthetic event stream that told me whenever those two things happened at exactly the same time? I could listen for the .all operator.

[00:07:40]
That's a stream operator that says I'm only gonna fire an event on rsq3. Whenever I have an event from all of my input streams. So if the key press happens first, I'm gonna wait until I get the button click, and now that I have these two events I'm gonna put those two together and fire them out on the rsq3 stream.

[00:08:00]
So I've created a synthetic event stream based on the composition of two lower level streams. That's .all, and by the way in RxJS terminology .all is called .zip so in RxJS they have a zip. There's an alias if you like the RxJS terms, you can use dot zip here, I just, zip is weird to me so I used .all.

[00:08:22]
And there's another one called merge in RxJS, which I called .any that says, I've got two or more incoming streams and I want to fire an event any time I get anything from any of them. So just fire him out as quick as soon as I get one from any stream fired it back out down the stream.

[00:08:38]
And that's called the merge in the arcs chance world. Here's the Rx marbles if you want to go back and look. So zip is the RxJS terminology for that stream operation. And you can see that one comes out on one stream and A comes in another as soon as A shows up.

[00:08:59]
An event is fired on the output stream called 1 A with the data 1 A in it and then when 2 and B show up then 2 B goes out. C and D come together but we're still waiting on a 3 and then we get 3 C and 4 D.

[00:09:17]
So that composite stream down there is a higher order stream to defined as a composition of two or more input streams. This is one of the most powerful techniques that you can learn. Is understanding how to model the data that's flowing through your app or operation, your application.

[00:09:36]
As a series of stream operations without practicing what I'm saying it's going to feel very esoteric and we are to you I understand that. But I promise you if you start practicing orienting your application around asynchronous events and using these higher order stream operations. It's like another set of light bulbs go off in life.

[00:09:59]
Wow, how did I ever get all? How do I ever get around not using that as my way of modeling data flow? So it's right that people are super excited about this reactive programming thing. It's gonna completely change a whole bunch of really crappy stuff that we've been doing for a long time.

[00:10:17]
The other workshops from Freddy Mausers like Jeff's workshop, fantastic workshop. It's all in on observables. It's all observables all the time and it's great. Netflix is using it, Microsoft's using it, everybody's really in on this observables thing. So I think we should we owe it some attention. We owe it our attention to kind of learn that and see that.

[00:10:36]
I think if promises and generators represent the baseline, the thing that's right over the horizon is observables are gonna be what everybody is using. It doesn't mean that promises are gonna go away but it means that observables are going to be a really powerful tool in our tool belt.