Reactive programming is a way of coding with asynchronous data streams that makes a lot of problems easier to solve. RxJS is a popular library for reactive programming that makes it easy to respond to UI events, asynchronous HTTP requests, timeouts, and other data streams in a uniform way. Give it a try and you might find that reactive programming makes a lot of tough coding situations much easier.
In this course, instructor Andrew Burgess will teach you how to use RxJS. You'll see how the simple tools it provides can be applied to a wide range of coding problems—follow along as Andrew shows you how to handle a number of common challenges with RxJS. After that, you'll get a chance to build a complete, if simple, game using reactive principles.
1.Introduction2 lessons, 07:35
2.First Steps in RxJS3 lessons, 31:12
3.Practical Examples6 lessons, 1:14:49
4.Code a Game with RxJS6 lessons, 46:49
5.Conclusion2 lessons, 09:35
1.2 What Is Reactive Programming?
If you're watching this course, you probably have some idea of what Reactive Programming is. But just in case you don't, I wanna start by getting us all on the same page. So in this lesson, let's answer the question, what is Reactive Programming? No introduction that I could give to Reactive Programming would be as thorough as the one written here by Andre Staltz. You've probably seen this article before, it's entitled The introduction to Reactive Programming you've been missing. This article is pretty much required reading for this course. So if you haven't read it, go ahead and check out the link beneath this video. As you can see, right down here, Andre says that reactive programming is programming with asynchronous data streams. And I think that is a very apt description, but, of course, this begs the question what is an asynchronous data stream? Well here's the way I like to think about it. I like to think about it as a cross between an array and a promise. All of us are familiar with arrays. An array is really just a wrapper around a set of zero or more values right. You can have array of nothing or you can have array of as many items as you'd like. And that wrapper around those objects or values just keeps it manageable. So we don't actually have to have potentially dozens of variables for each one of those values. We could have one object, the array, which encapsulates everything and makes it easy to manage. And most of us are probably also familiar with promises and promises are also a wrapper. But a promise is a wrapper around a value that we don't have yet or maybe we do have it but we don't really know. The nice thing about a promise is that it, again, is a wrapper that keeps values manageable. We don't have to worry about whether we have the value or not or when it appears. We just tell the promise once you have this value, then do something and it will do it when that value appears. So an asynchronous data stream is a combination. It's a wrapper around zero or more values but it's a wrapper around values that we may or may not have yet, values that we will collect over time perhaps, or maybe receive all at the same time. It doesn't really matter, but the point is our asynchronous data stream manages all those details for us. You can see a simple example of this right here in the article if you look at this marble diagram. Marble diagrams are actually quite common in reactor programming because everything really can be thought of as values over time. This is a asynchronous data stream. And those data elements in this stream are click events. So you can see right here we have clicks on a button. The black line here represents the stream itself, you could say. And each one of these circles represents some event that occurs. And of course this line as it goes along time continues. And as you can see over time the button is clicked. And so each time that button is clicked, we get some data and of course in the case of a button click that data is an event object. Now streams also have two other types of things. We can have an error on a stream which is represented usually by a red x, and we can also have the completion of a stream. So a stream can end. A stream doesn't have to end, but many streams do end. And so, as you can see down here, it's written, a stream is a sequence of ongoing events ordered in time. And so, user clicks on a button are a basic example of an asynchronous data stream. Now, initially, the idea of data streams may seem a little bit foreign and it does involve a little bit of a paradigm shift in your programming. What I hope you'll find as we go through at this course, is that almost any data in your applications can be represented as a stream. Now you've done fine without using streams up until now, so the question is, why should you try reactive programming? Well, one reason might be the organizational structure that it enforces on your code, and there are other reasons, as well. But for me, one of the most important reasons is because you can use functional programming methods and techniques. Now there is such a thing as functional reactive programming and that is a little bit different from reactive programming. We're not really going to discuss the difference between those things in this course. But a lot of what we're doing, in some ways will be functional reactive programming. And this is actually what ReactiveX or RxJS for us is. It's a set of methods for functional programming in the context of asynchronous data streams or what RxJS calls observables. And in fact, you will find that there are a lot of methods and things that are very similar to functional programming methods that you might use with arrays. Another resource you might want to check out is the RxJS book and I will have a link to this below. This is written for RxJS version four and we're going to be using the version five beta because RxJS version five is pretty much I believe a complete rewrite and there are a few breaking changes. But as you can see the example they have right here at the bottom of this first page shows how similar functional programming can be in a reactive context to just using a regular array. So on the left here you can see we have an iterable example which just means using a regular array. Over on the right here we have an observable example which is using reactive programming. In an iterable example or when you use an array, you might get an array from a function called getDataFromLocalMemory(). Then you could go ahead and filter that array, you can map over that array and then you can do something for each element in the array. In the observable context, you can get data from a network and of course that is an asynchronous operation. And so instead of turning just an array of data, this actually returns an observable. Now that observable may just return a bunch of data all at once, or it may return a bunch of individual pieces of data over time. It really depends on the type of network you're connecting to. But the point is it doesn't matter because, since this returns an observable object, we have a uniform API we can use for all those different network scenarios. We could go ahead and filter over the data elements that are returned, we can map, and we can subscribe to the result. And subscribe is pretty much the observable Version of .forEach. So I like this example because, using an observable and reactive programming can seem a little daunting at first. But once you realize that if things get confusing, you can just kind of think about it as arrays or asynchronous arrays, then things become a little bit simpler. So I'm sure you are still a little bit confused with everything I've just thrown at you and really that's okay. The only way to clarify things I think is by digging into some code and so that's what we're going to do for the rest of this course. I hope we can look at some examples of reactive programming with RxJS and make reactive programming both understandable and fun.