Manipulating Time

[00:00:00]
>> So now, we'll talk a little bit about manipulating time. So I've got another example in here called manipulating time. And this looks like the notifications that we had previously out of the box. It does exactly what we had before. Let's go and let's see some of the fun tools that we have at our disposal.

[00:00:22]
We'll start out with a very simple operator let me go over to manipulating time. And you can kinda see some of the ones that we have to work with. I've already imported them here for us. We've got delay to bounce and throttle. We've got some of our old friends scan, map, and tap.

[00:00:42]
But the ones we wanna talk about delay, to bounce time, throttle time to bounce and throttle. These are ways as we talked about before, if someone starts rage clicking, maybe we don't wanna slam the API, right? Maybe we want to ignore things. A common use case that we might, use RXX for is figuring out, okay, they're they're typing into an autocomplete, right?

[00:01:09]
Every keystroke, every keystroke who wants an API request for the search API? What about if when they're done typing for like 300 milliseconds, then we'll go send one over. And so there's a bunch of the ability to control the rate at which things happen is set of super useful operators.

[00:01:29]
So let's take a look here and let's see what we can learn along the way. So we have this button and we wanna delay it two seconds, five seconds, however many seconds you want into the future. So we can pass in the delay operator and save that. And now and go ahead on the city to Mississippi, and it shows up.

[00:01:52]
Right, now if I rage click, one Mississippi, two Mississippi, and here they are, right? Cuz there's only delay in them two seconds from when they started that's spacing them out by two seconds, it's simply delaying them. There's a whole bunch of really interesting ones there are buffer, which will collect all of them in a certain amount of time and give you an array of all the things that happened.

[00:02:10]
There's a whole bunch of ones that probably aren't common enough to make it worth our time in a fundamentals course. But definitely, at one point, you'll have one use case where you need these, and they are there for you. But the common ones that we might have is, be cool if we could stop the rage clicking.

[00:02:27]
Especially cuz, once you add a delay to anything that's slow, I mean, I wrote this and I wanna rage click it when it takes two seconds. Right. And so what we could do is we could say, throttle time two seconds. And I'll repeat this a few times cuz it bears repeating.

[00:02:51]
Throttle time into balance time are basically two sides of the same coin. Throttle time says let's think through and then ignore things for however long, right? The bounce time is going to be ignore everything, till two seconds of quiet have happened. I'm apparent to this, I relate to this.

[00:03:13]
Until the two seconds of quiet, and then I will do whatever it is the last thing that was queued up for me to do, right? So total time is, I'm busy, wait a minute. The bounce time is, I need a moment of peace, however many seconds of silence and then I will go do whatever I meant to do.

[00:03:32]
So here we can put it away two seconds let's just get rid of that let's just say throttle time it's now I can go to town on this. And really about every two seconds you'll see another one up here, even though I am out of control. Right. And then we've got to bounce time for two seconds, which is don't do anything I can keep going I can keep clicking and go out of control here.

[00:04:04]
I can trigger whatever it is that thing I never want it Mac OS to do. I don't need the dictionary word my browser but I can keep clicking on it until I stop for two seconds, then we'll see it actually happen again, autocomplete is a great use case for this, right?

[00:04:22]
I don't wanna hit the API until I've chilled out for a moment, I know they're done, right? Anything that might be potentially expensive. Like most in browser if you're rendering markdown, for instance, it's pretty quick. But if you have something that was a little bit more long running let's not do it every keystroke.

[00:04:37]
Let's do it at a natural pause, right, usually about 300 milliseconds is being good time at that point and get a sense for it. And then we've also got just throttle and debounce and those work like, skip until and take until. Which is basically in total, another observable emits a value, either, ignore things until this other observable emits a value or do a thing and then stop listening until something emits a value, right?

[00:05:12]
And so you have two things that maybe are dependent you can then tie them together with just throttle and to bounce. Effectively we'll look at a right to throttle time and to bounce time in a second but we also have that panic button on the screen which is just I couldn't come up with a better name for a button to be honest with you.

[00:05:29]
So say panic clicks is from event panic button, button, button click, and so we've got that now we could theoretically to bounce, based on panic clicks. Just so the JavaScript doesn't get angry with me, let's do it in order. What happens to observable if you don't subscribe to it?

[00:06:03]
>> Nothing.
>> Nothing. [LAUGH] Nothing happens you observe. The verbal exists and no one's around to subscribe to it. Then it doesn't really matter. So we don't actually care what this one does in this case. And again we'll find ways to kinda batch them and automatically subscribe and unsubscribe a little bit but we do know that we need to subscribe to it otherwise it will never emit event.

[00:06:25]
This one actually returns the observable that you need in this case. So here's the observable it needs a factory function in this case, right? Cuz it's not I think that'll work actually because this will So basically do what I just threatened to which is, this function will return an observable that to bounce will subscribe to.

[00:06:49]
Keep hitting it until they hit the panic button. So this gives this function creates an instance of the factory function. Create an instance of a panic click observable. Once that admits it will then go ahead but through Serato, we'll do the opposite. Where we can create a notification, but nothing happens until we hit the button again and then we're allowed to have another one throw.

[00:07:17]
Right? So there's different ways to basically start and stop different events from flowing through. I would argue that throttle time and to bounce time are probably more common but if you find yourself okay once they started dragging ignore stuff until a drop event happens. So on and so forth you have the ability to have control over different events that fire and begin to orchestrate them and coordinate them.

[00:07:42]
>> At some points a predict a being smooth or like very responsible the prediction becomes very resource intensive so not setting 300 millisecond waiting for events to add. Do you have a sense of your comment on how RXJS handles that if we are if we want to wait or want to wait for the end of the session, how much resource, how much load is going to get placed?

[00:08:06]
>> I mean you are you're playing with memory in this case, the more you keeping track of the the more memory you're managing, right? There are ways to basically coordinate between switching between two example observables exist so later we'll look at exhaust map. So exhaust map says cool until I'm done with what I'm doing, ignore everything, right?

[00:08:30]
But it will kind of orchestrate and coordinated for you. Switch map will say, forget what I was doing. I wanna go do this new thing. And some of there are optimizations under the hood. So for instance you're using from fetch, and you switch map and it stops caring about the results of that fetch, it will actually cancel the fetch request request, right?

[00:08:50]
And use the bar controller on the Fetch API. So you can kind of do stuff but yeah, the more you are keeping track of, the more memory you are going to use as you and so everything is a set of trade offs. It depends on what you're optimizing for.

[00:09:03]
If it is optimizing for DDoS in your own back end, then a little bit of memory usage probably isn't the end of the world. However if you're already playing on the edge then you might choose to handle it differently.