Redux Thunk: Dispatching Actions

[00:00:00]
>> Steve Kinney: We've got the action creator in place. We do need to, right now we're just console logging it and we can give that a shot. Let's see if it knows node-sass decided to play along.
>> Steve Kinney: Cool.
>> Steve Kinney: So right now this is console logging. All right, we did all the waiting for the promise to resolve and then we solved that with just a console log.

[00:00:25]
But you can see we got the tweets. So now we just need to dispatch the actual action. And when that happens, then we'll be able to update the page.
>> Steve Kinney: So we'll go to Actions, and we'll say hey, you know what? We've got this dispatch.
>> Steve Kinney: What we can do is we'll make another action creator.

[00:00:50]
We'll say, actually, let's go to the top real quick.
>> Steve Kinney: ADD_TWEETS, or UPDATE_TWEETS, or whatever you want to call it. We'll add those tweets, we'll make another action creator, which is the regular one we expect out of Redux. So we'll say, addTweets, that's going to be tweets. And it will just return a new object that will be the type: ADD_TWEETS, and the payload will be the tweets.

[00:01:27]
It's like a payload of tweets. Man, 20-20 hindsight, that should have been a meme generator. And this should have fetched a bunch of memes. There should've been a payload of memes, cuz who doesn't want a payload of memes? All right, so instead of counsel logging, we're just gonna dispatch and this is exactly how we would have done it in a math props or anything along those lines, it's no different.

[00:01:46]
Cuz like I said, we and WIN stuff are made by the same people. We'll add the tweets with the response dot tweets. There's some other things in there, I think I included the search term and the API and a few other things. So the map dispatched to props is gonna trigger that fetch tweets action creator, which is actually gonna dispatch a function that is gonna go ahead and basically wait for the promise to resolve.

[00:02:14]
And when all that is done, then we'll dispatch the one that Redux can actually handle, just a regular old object that we would have had, right. So it's basically an intermediary step. Hey, go do this quote unquote side effect. Get me the API results and then we'll take it for a spin.

[00:02:29]
The problem we have is that none of this exists in the reducer. All right, we just [LAUGH], cool, an action up and neat, here's the thing tweets again, we'll just say action type.
>> Steve Kinney: Tweets are auto import, which is my literal favorite feature in Visual Studio Code. And then we'll just return the action.payload.tweets, a payload of tweets, cool.

[00:03:01]
>> Steve Kinney: Fetch them, there they are, right? We hid the API, we updated redux. Everything was great and wonderful. Cool, and that's effectively it. Now there are things that we could do. You, and I'm not gonna take this all the way, I'm just gonna kinda show you a little bit.

[00:03:24]
The kind of interesting thing and in the first version of the fire base and reactor cores, we actually used redux thunk and hooked into Firebase, which will kind of send you like websocket notifications of the data changes. The really cool thing that I have noticed you can do with Redux thunk, and it's probably only somewhat recommended, is you can dispatch multiple actions, right.

[00:03:48]
So we can, for instance, we can create a new action that sets the status to loading, right? And then, there's nothing stopping us from dispatching that. You can call dispatch as many times as you want.
>> Steve Kinney: So there, we'll dispatch this set status to loading, right. And then we might have another one upon dispatching a tweet, so we might take it down.

[00:04:15]
We could catch the promise and dispatch another error. The problem here is that you're kind of on the hook for doing all of these, right? You can dispatch multiple times and your redux store can like, all right? We fire the loading event as soon as we get ready to make the AJAX call, that updates the UI in some way, shape, or form.

[00:04:36]
Maybe it disables the button from the user clicking it again, right? There's all sorts of stuff you can do here, and then we hear back, we can dispatch the fact that we got the tweets. If the promise fails, right, we can catch that and we can go ahead and say, okay, it didn't work, and set an error status.

[00:04:51]
You can dispatch multiple times in here, and kind of begin to figure some of this out yourself, which is a pretty cool way of doing it. I'll leave that kind of as an exercise for the reader. Now, I kind of hinted that this is not a silver bullet, there are some issues here, right?

[00:05:13]
You are on the hook for doing everything. One of the fun parts about working at a company that's major product is its API is that sometimes, we have APIs that weren't necessarily intended for frontends, right? And so to get all of the data that I need to display UI, I have to get stuff from three or four different APIs, all right.

[00:05:39]
We saw stuff with with canceling, so on and so forth. There's a lot of stuff that you're kind of on the hook to do yourself, at which point, it is definitely worth thinking about. There are some other drawbacks here as well. For example, what are you gonna do if you need to test this, right?

[00:06:01]
You can't separate. You're dispatching this function that you can't cancel. And you're gonna have to do something like this if you wanna test it, which is you're gonna have to use a fetch mocking library that's gonna mock out the fetch API to give you some data. Because you can't separate the dispatching of that function from the execution of it.

[00:06:24]
So you have a button that has an action creator that maybe wants to do a thing, it's kind of harder to test, right? There are a bunch of libraries that kind of separate out all of your async stuff from the rest of Redux. Now Redux still has a lot going for it in so far that it's simple.

[00:06:43]
But that simplicity puts you on the hook, like as I've said. So there's a few libraries that we can use to kind of make this a little bit easier. And last time we went to the advanced state management version of this course, we used Red-Saga. And Redux-Saga is great.

[00:07:05]
This time around, we're gonna talk a little bit about Redux-Observable. They are basically two versions of the same idea, right? So we have that kind of reference material if you're really interested in Redux-Saga. The reason I chose to do Redux-Observable for this version of the course is predominantly because it's the one that we use.

[00:07:25]
All right, I thought, better off speaking to some of the intricacies of that one. At the time, we were still, last time we did this, we were still kind of evaluating, we were using Redux-Saga for some smaller projects. But the large application we use, uses Redux observable