Redux Observable

[00:00:00]
>> Steve Kinney: Redux Observable is effectively binding Redux to RxJS in the same way that React Redux binds Redux to React. I'm pretty sure we have full courses on Observables, so I will not go all the way into Observables. This is kinda again beyond the scope of this, we use a very limited set of RxJS.

[00:00:23]
I think we aspire to use more, there's a lot more that we want to use, but currently, baby steps. So we'll talk about enough RxJS to be dangerous, without getting kinda too deep into it. So Redux Observable, we should be pretty clear on the Redux part, but what is this observable?

[00:00:43]
And observable you can think about as a stream, think about an array over the dimension of time. Where things are coming in, and this could be, for instance, things streaming in, when we hear back from the API. It could be stuff off our website, it could be mouse movements, right?

[00:01:02]
Anything that happens over the course of time is probably a good candidate for an observable. And then the cool thing about stream is that it's cancelable. You can start listening to the series of events, and much like an eventometer, you can stop listening when you're done. Great, so the interesting thing is all of our Redux Observable has a thing called an epic.

[00:01:24]
There's a bunch of fun words for all these libraries, like Redux Saga, Users Saga, as in like what is that? It's a term from the '80s, again, like a lot of front-end thought leadership. Is taking things that we were doing 30, 40 years ago, and building libraries around our modern frameworks.

[00:01:42]
So it uses this idea of an epic, which obviously raises the next question, what is an epic? An epic is actually bizarrely simple, even though when we look at some of the code, it's not. It doesn't seem that way, because a lot of the complexity when we see the code is RxJS.

[00:02:01]
Which again, I'm not gonna go all the way into, I will leave it as an exercise for you. But I'll show you how we can hook it up all together. And so, an epic is a function that takes a stream of actions dispatched, and returns a new stream of actions.

[00:02:17]
So a way to think about it is you've got an action, it goes into the epic. Another action spits out the other end, which is weirdly great. Because it means that when they hit the button saying like load the tweets. That will fire an action saying load the tweets which Redux can deal with, you can put up a loading thing.

[00:02:37]
It goes through the normal flow, the epic can then go like I'm making an AJAX request, and I get that. I'm gonna figure out all this other stuff and then I will fire a new action. I will take that read the tweets action, do some stuff, and I will transform it into a new action that has some tweets.

[00:02:53]
And so all of your Redux-base stays completely unaware, but it's effectively all of your React and your Dispatch. Is dispatching normal Redux actions that are going through the normal flow. Your whole React Redux application really doesn't deal with any of this stuff. The epics are just quietly listening to all of the actions that flow through, that's were the Observable comes in.

[00:03:14]
To all of the actions that are flowing through the system, and occasionally they'll be like, I care about that one. Let me go make a AJAX request, then I'll fire another one and I'll transform that into a new action. But I want to point this out again, which is the actions still go to their normal way.

[00:03:32]
So if you fire a [INAUDIBLE] of tweets, that's still going through all the reducers. The reducers can choose not to listen to it, but this middle work kinda sits outside of your normal flow. And it's just listening to every action that comes through, if it's an action that you decided that you care about.

[00:03:46]
It pays attention to it, it transforms it, and it does kind of the next thing. So here's the default Redux Observable example. This is a normal thing, which is like, hey, if we get the action type PING, return Pong, right? So listen for every action, this theoretically is not really a reducer, this is a regular JavaScript.

[00:04:11]
This is not an epic, this is what it looks like in an epic. So listen for all the actions and that dollar sign is a same way like we use a dollar sign in front of variables that are wrapped in jQuery. It's just a way for us to know that this is an observable.

[00:04:27]
For every action that comes in, all of them, if it's an action of the Type( 'PING' ) map it in the same way you would map over an array. Cuz again an Observable is an array over the dimension of time. Crazy, right? Everyone that comes in if you have the Type( 'PING' ) map it to PONG.

[00:04:49]
And so what that basically does, is it just transforms actions as they come through, and it's just constantly listening. That's great to talk about, we're going to look at that second example. With the Star Wars Autocomplete, cuz that does a bunch of things. There's a definite case where we want to cancel an AJAX request.

[00:05:10]
You won't necessarily stop the browser from sending that out. You're just being like, yo, browser, I've moved on, I think we should do other things. So an Autocomplete is a good example, it's just, you might fire off an AJAX request for every key stroke. But you only care about the most recent one, you don't care about all of them.

[00:05:31]
You just care about the last one that happened, so basically, you wanna stop listening. Cuz what will happen is, let's say, generally speaking, we have an Autocomplete. You're gonna fire them off after every keystroke. And given normal network conditions, they're gonna come back in roughly the same order.

[00:05:48]
That's not actually true, right? With intermittent network connection, you might have your last one not show up. And then a previous one come back slowly, and stuff like that, and it could get weird. So you might be like, I only care about the most recent one. And that's the problem that we're gonna try to solve for.