Creating an API Data Stream

[00:00:00]
>> All right so here's the challenge. We know how to do things on a regular interval like change the number on a screen, we know how to fetch data change a number on a screen not that impressive. However, there you can see a world and this is where I had to implement this last week, which is like cool, fetch the data.

[00:00:24]
But then fetch it again, every so often, right? Like every 30 seconds every minute. Like if you're working on like, let's say a dashboard right? Maybe you have long pole and we have WebSockets maybe you don't, right? So depending on what you have available you might have to take different techniques so one is simply to refetch at some kind of reasonable interval, right.

[00:00:48]
So how would we combine a little bit of what we saw with starting and stopping observable with theoretically, pull up some data and then every so on and so forth, refresh and reload that data, right. That is definitely a probably more realistic use case then a counter, right but effectively under the hood, it's just a counter, right?

[00:01:14]
It's the same concept. It's just sometimes you guys snap two things together for to be somewhat impressive. So, okay, how would this work? I'm going to move my error back in because the one of the reasons why I had it in here so I can make this one kind of contiguous piece of logic.

[00:01:33]
So we have this ability to theoretically to fetch from fetch to fetch some data this seems like a great candidate especially because if you find a world where observable is getting a little gnarly. Because it's getting kind of big you do the same thing you do with any other piece of code.

[00:01:52]
You take your big ugly piece of code and you break it into smaller uglier pieces of code and then you hide them in different files, right? And that is how you develop software. So, let's take this logic of fetching cuz we're gonna let do it more than once.

[00:02:10]
We'll say fetchData. That seems like a great name for this. And we can go ahead and we can pop this in here and we'll grab all of this logic that should be it right, yep. All this logic here and we'll pop it into that function. Great, awesome. So now our exhaust map really becomes this.

[00:02:37]
This is what we're dealing with whenever they hit the fetch button, right we're simply exhaust mapping this factory function that will return an observable, right? Very similar to what we saw, when we returned one from throttling. But it's same thing you do with a map on an array.

[00:02:56]
So we've got that. This fetch button seems good, but instead of having it immediately trigger, we're going to start the process have at a regular cadence fetching that data and refreshing it. So we'll go and set like we've seen this before we saw it earlier where we can map to true in this case let's make sure the VS code likes me today yep map to is available sweet.

[00:03:27]
And then the other button is what is the stop button this time? So we'll call that stop button, Leaving spell false right this time, so now we've got very similar to what you all implemented with the counter before. Right we have the ability to emit true events and false events.

[00:03:51]
What's the next step? I need both of these
>> Merge them.
>> Merge them, right? Let's call it I don't know a facts stream. Naming things in computer science is hard. We'll merge the fetch event and the staff event. And we'll pipe them. So now we'll get both of these.

[00:04:21]
So exhaust map because we only wanted to deal with one at a time, but in this case, these will be synchronous. But what is the correct? If I want to switch between fetching and not fetching what kind of map should I use?
>> Switch.
>> Switch, right? I will care about the most recent one.

[00:04:41]
I don't care if I use a merge map I'll keep making more streams, right? Every time I start and stop, I'll create that many more nevers or fetch events. So what we want is a we want is a switch map so we only care about the last time they said start or stop we don't care what happened in the past we live in the now.

[00:05:04]
We deal with the current situation so switch map we'll call it like, should I or should fetch seems more confident. Cool, and let's see if they should fetch. Does it go right? Should I fetch but I don't this is a coach's job to figure out mine. And if they should fetch, then what we want to do is return a timer that fires immediately because they hit the button.

[00:05:35]
Let's not interval will wait that amount of time before the first event is emitted timer fires immediately and then again at whatever cadence you tell it to. So timer fire right now. And then again in five seconds, every five seconds, so we'll say pipe and I really, I could do this, subscriber's gonna be the final event in this case.

[00:06:00]
What I really need to do now is clean up the file fax and the error message every time, right, because this case we want to hide them and replace them. And I want to clear the error message out like this fetch is only gonna give us the final value of the subscribers only give us the final value, that's not useful for us anymore so.

[00:06:16]
So what we'll do is we'll pipe in will say tap. Clear the errors, also tap and I could do these both in the same. I just chose not to. And now this is where we'll put that exhaust map that we had before. So, when they should be fetching immediately, then every five seconds we'll clean up the UI, and we will go get new facts.

[00:06:52]
Right now we could theoretically be like, actually, I want to keep the facts until we get the new ones cool. You can do that later and if we should not be fetching Switch them to just a moment of silence, right? And so now we have the stream that goes switch back and forth.

[00:07:14]
Again, it's merging it's two sources are the start and the stop button. So the fetch and the stop button. Based on that, it is either going to point us an observable that is gonna keep making that API request. And the cool part about this is not only is it gonna create the API request, but it has all that retry and error catching logic as well right?

[00:07:36]
Or if they say I'm no longer interested in getting new dog facts, that's a personal choice I respect that then we switch them to the never stream a silence, so they can talk all back and forth between this. So we don't need that anymore. So we'll say our back stream, I'll subscribe Add facts in this case so whenever a value comes through which again, in the off case it will never come through.

[00:08:12]
Thank you VS code in the fact stream nothing will ever come through so there's nothing to add to the page. If I used empty instead it would technically omit nothing then complete, that's not what I want I just want radio silence until I switch back to some of the values.

[00:08:29]
So is this what always blows up, which is not what I want in this case. And I might want to keep some of the, I guess I'm not showing there in this case. So the code that I had before was probably useful but let's find we'll make it successful.

[00:08:41]
We can change it later if we want. The code that I had before it was like okay, if it's an error show the error I just said like, no matter what are the facts if you get this error object, things go poorly again. Well, we can switch that back.

[00:08:52]
But we can also make the API fail. All right, let's see. All right, so I get some dog facts. I think it still had a delay on it. They clear out. I get new ones. This API still has a delay. Like I said before, we could choose to, wait until we got the new ones, and then show them, that's again, how?

[00:09:13]
That's when you start to play around the order of operations here, and you basically have all the tools necessary to do that. So you could theoretically, immediately, you could even do in the subscribe. I have new facts, go clear out the other ones as shown on the page.

[00:09:28]
But if I took out the delay, we can see it as well. So let's make a regular API again. And so what's cool about this is now I have complete control with just regular JavaScript objects. It's not like, okay, set this interval clear this interval on mount, on load I have this stream.

[00:09:49]
I can listen to it when I'm ready to listen to it. I can stop listening when I wanna stop listen to I'm not thinking about intervals or anything like that. Again, like in a framework where you might make this kinda interesting for yourself is component did mount component will unmount use effect?

[00:10:05]
What have you, like start listening stop listening. So here they'll just kind of refresh at a regular interval. We have dog facts streaming at you live and then we can stop it and they will stop fetching, right? So we combined a lot of concepts here. Let's just kind of, let's celebrate ourselves for a second and talk about what we did.

[00:10:38]
We have a fetch situation where not only will it catch an error and display, some UI, it will retry. It'll handle all of the kind of different error states around that. We can then also take that, and set it to work on timers. We took everything we learned about the counter, and setting timers and starting and stopping flows.

[00:10:59]
We took everything we learned about async. And, we put them together into like basically one kind of concept. So, you can start to take these different ideas and snap them together to solve different problems that might come up.