Let's talk about "Reactive Programming." You may have heard of the "Introduction to Reactive Programming You've Been Missing," a gist which I wrote. Maybe it's too long for you to read the whole thing. It's all right. We can explain it through this series of lessons.
A lot of people have heard of reactive, but it sounds too cryptic, too scary, and advanced. For instance, sometimes you see a piece of documentation that looks like this, flat mapped lattice with observable sequences. This can get really confusing.
This series of lessons is here mainly to help you to grasp the core idea in Reactive Programming and to help you how to think in Reactive Programming in order to apply it to a real code base.
What is it? Well, it's mainly programming with event streams. Now, what is an event stream? It's a sequence of events happening over time. You can kind of think of it as an asynchronous array.
Here's time, and it goes forward, to the right. Events happen over time, and we can add an event listener to this whole sequence. Whenever an event happens, we can react to it by doing something. That is the main idea.
On the other hand, event streams don't have that property. So, the events might happen over time, and you don't even know what are the items that might happen.
Here we have those same items that happened in the array, but we have them happening over time every 400 milliseconds, like this. We add an event listener to the source, event stream, by calling subscribe. Whenever an event happens, we just console log that out, and we saw it happening every 400 milliseconds.
It's different than arrays, because here if we just console log the array, we see the whole thing at once. The nice thing with event streams is that they have similar functions like arrays do.
Let's say that our problem is to add all the numbers in this array. Right? As you can see, they're not actually numbers. They're strings that look like numbers, we have to do some transformations here. You might want to feel like using for loops for doing this, but we're going to use map and filter and these stuff, which is the function approach.
Let's take this source array, and we will map each of these items to their parsed version. This will return a new array. That is important. Source did not change. We just made a new array that will be called "Result," where each of these items is mapped. If we log that Result array, we get this.
Sometimes, it was not able to parse it, so we saw not a number. That's how we use filter in order to ignore those which are not a number. Then we get yet a new array with only numbers.
Now, since we want to add all those numbers, we need to call reduce by giving X and Y, where X is the previous item and Y is the current item while we're iterating over the array. We can add them. This reduces instead of returning an array, it will return us a number, which is what Result is. Then finally, we see that we added all the numbers.
We can do the same thing with event streams, actually. Here, we can get this source event stream. It's not an array. We can map over it, getting each event X and mapping it to parsed Nth X. We see basically the same thing, but happening over time.
Obviously we can call filter. And then we want to add all those numbers, so we're going to call reduce. There we go.
Now, it's ticking over time, adding all those numbers. When it ends, it returns us 33. That is basically programming with event streams.