Transcript from the "Async Functions" Lesson
>> Brian Holt: Now, go to Action Creators. The first thing that I wanna do here is import ADD_API_DATA. I'm gonna export another function called addAPIdata,
>> Brian Holt: It's going to take an apiData, which is going to be of type Show, right?
>> Brian Holt: And then in here we are going to return a well formed action object, which is going to be of type, ADD_API_DATA and payload: apiData.
>> Brian Holt: So in particular here, we're actually not gonna be calling ADD_ API_DATA outside of this particular function, right? We're actually gonna handle this inside of action creators, but it's a good idea to export it anyway. Say, for example, you got API data, maybe from local storage, right? For example, you could use this add API data action to kind of load it from different sources, right?
[00:01:16] This is going to be useful other places other than just stuff coming back from the API. That's why it's good to do that. This is also good because now this is testable, right? So now I can import it into my test suite and test it, and it's a good idea to test action creators.
[00:01:32] In fact, we're going to do it. So, cool, okay. So now, Everything's all ready for us to start adding action, or API datas into our readout store. Now we wanna tackle the problem of making that asynchronous request inside of a thunk. So what we're gonna do now is we're going to export another function called get API details.
>> Brian Holt: Okay, this is going to take in an imdbID, which is going to be a string,
>> Brian Holt: Okay? Now these action creators always return objects, right? That's kind of the contract there. However, this is going to return a thunk, right? And so what is a thunk? A thunk is a function.
[00:02:27] It kind of throws people off, but remember that we are dispatching this function into the Redac store and then redac is going to say cool. This is a deferred action so something is going to come from this. I'm going to call this function and wait for it to dispatch, okay?
[00:02:41] So that's why here you're gonna say return function. So it's gonna be a function that has dispatch injected into it, which is gonna be a function.
>> Brian Holt: So that's why we're returning a function here.
>> Brian Holt: And then in here we're just gonna do pretty much what we were doing inside of details.
[00:03:14] We're just gonna make our axios request here. In fact you need to go import axios at the top. Import axios from axios.
>> Brian Holt: Okay, and then we're gonna say axios.get. And this is gonna go to http://localhost:3000/, and we're just gonna put that imdb id right there, okay. And then we're gonna say .then, thine, .then, response.
>> Brian Holt: And the response is gonna be something that the API gave back to us. All we're gonna do at this point is now we're gonna use this dispatch function, which Redux gives you to dispatch an action, right? So this where the thunk is resolving and finally giving out an action.
[00:04:16] So it's gonna say dispatch(addAPIData(response.dat)).
>> Brian Holt: Then, as always is the case with an API, it's usually a good idea to have the catch statement at the end just in case something goes wrong. It's gonna be an error, and here, I just say console.error so that it doesn't get dropped on the floor.
[00:04:44] axios error, error. It's gonna warn here, it's gonna say, hey I don't like console.log, it's going down to production, but for me, this is useful to have as a developer. So I'm just gonna say, hey ESLint, go ahead and shut up about it.
>> Brian Holt: So we're just saying, hey, disable the console warning just for this particular line.
>> Brian Holt: So to recap again, this is a thunk, this particular piece, this function, that gets returned here? That's the thunk right? The thunk function is going to be invoked by redux right? The redux thunk thing that middle ware that we put in there, it's going to inject this dispatch function to say cool.
[00:05:46] Go do whatever you need to do and call me back whenever you have the action that you want to do, right? So what we do is we go to our API via axios and once it resolves it then says cool, now I have the action data that I want to dispatch.
[00:05:58] So I call them dispatch, with add API data which gives me back a real action object which then gets passed into Redux. So this is how you do asynchronous code with Redux. So I would say thunks are the easiest way. I don't wanna say easiest, maybe simplest, there's just not a lot to it, it's just a call back, right?
[00:06:20] But there are other ways to do this. You can dispatch promises, with Redux promises. Observables with Redux observables. And generators with Redux saga, and I would say those are the most common ones.
>> Speaker 2: There´s a bunch of debating going on about-
>> Brian Holt: Which one is the best-
>> Speaker 2: Redux.
[00:06:35] The whole fact that you have tons of actions and how the scales. Whether or not someone like Facebook is using Redux across-
>> Brian Holt: I assert pretty unequivocally that this does scale, right? So right now if you go to our redux´s file, we have all of our reducers living in one file, typically in a large application.
[00:06:59] You´re gonna separate reducers into separate files, but when you´re using combined reducers, like this, this one reducer owns API data, right? It owns that one particular piece of the state tree, and it has no concept of search team for example, right? So the fact that these are siloed from each other is why this scales, right?
[00:07:19] If you were worrying about every single object and every single reducer, that gets unruly. Especially when you start getting 50 things in your reduct store, but the fact that these are so siloed from each other, I can keep them in separate parts of my application. And they can be tested individually, that's why this scales, for sure.
[00:07:34] I confidently assert that this scales.
>> Speaker 2: And then, what about adding typings to, say, some of the things you're returning and whatnot, to make the actions?
>> Brian Holt: Like this stuff right here? [SOUND] This, the response in the error typings are coming from the axios typings from flow typed.
[00:07:57] So that's why we don't have to type this. It knows that there's a response to that data. You can do it explicitly if you needed to but I don't think you need to.
>> Brian Holt: Yeah, there's nothing that you need to do with this in particular right now.
>> Brian Holt: And addAPIData, we already told APIData's gonna be a show, and that's fine.
>> Speaker 2: Does something like immutable.js help with the mutability of state?
[00:08:43] That you can't directly modify things, and it also allows for really fast checking for things like, is this the same object as thing? No, cool, they're not equal anymore. And there's no sort of deep nesting that you need to check, that definitely helps. My problem with immutable.js and why I don't use it and why I don't teach it is it's a pretty large library, and yeah, so I don't.
[00:09:05] The value that it gives my developer experience does not match how big the library is. The last that I checked, I think it was like 50 kilobytes, which is for me kind of a non-starter. I think it's bigger than react, which is a problem. [LAUGH] So it is cool, there are reasons to use it.
[00:09:22] I've just not so far chosen to use it. To be honest with you, a lot of that same similar type of benefits that a mutable is gonna gain you, you're gonna get from having typings with your language, right? Cuz it's gonna catch some similar problems, like hey you're modifying this and probably should be modifying that.
[00:09:41] So, a type system can help catch similar bugs, not totally the same. And immutable particular cases we'll have some speed benefits, just by checking high level, shallow checking is the same object as this. But so far I just haven't felt the need to use, personally.
>> Speaker 3: And a few people are commenting that they use react set state for UI state, and then redux for application state.
>> Brian Holt: Yeah, totally, we talked about that yesterday too.
>> Brian Holt: But I agree, that's a good thing to do.