Transcript from the "Middleware & Thunks" Lesson
>> Brian Holt: So, let's talk about async redux now. So, I've shown you, like, top to bottom, like that is core redux. Redux doesn't really do much else, in terms of redux itself. Like I said, it's a pretty small library. It carries a lot of overhead with it. And, like, now that you've seen it, I hope that you see the value in it, because I've shown you a really poor use case for it.
[00:00:24] A small application like this has no business using redux. However, I hope if you see if you have a huge app the central source of truth is a good thing to have.
>> Brian Holt: So, actions in redux are synchronous. Always, 100%, unless you modify redux in some way to make it not synchronous.
[00:00:45] But by default, with the way that redux comes today, with no other add-ons, it's a synchronous experience. And there's no real way to make it asynchronous. So let's go look at details real quick. So right now in componentDidMount we do our axios call inside of details to get the information that we need, right?
[00:01:15] Well, now that we have redux, it would be better. Someone pointed out earlier that if we go to house of cards, go back to the search page, and then we go back to house of cards. We re-request it, right? But if we made that data live in redux, we would not get that problem.
[00:01:30] Because redux lives beyond those page navigations. So how do we do that? Well, answer one is what we could do is we could leave everything the way it is. And instead of calling setState here in the then from axios, well, what we could do instead, is we could just call dispatch inside of the then statement right here.
[00:01:58] I'm not really satisfied with that answer. I feel like that's kind of a data fetching problem to hydrate what's in redux, and I feel like that should live with the action creators, right? They should live within redux not live in react. React should be more worried about user interface stuff.
[00:02:13] All the data fetching should live within redux if we're going to have redux, right? This is fine if all you have is react, this is not fine if you have redux. Does that make sense? Do we follow? Okay,
>> Brian Holt: So there are several ways of making redux handle asynchronous action by pulling in what are called middleware.
[00:02:34] Middleware is just augmenting the ability of what redux can do. Right now, like I said, redux, all you can do is dispatch actions, that's it. By adding a middleware you can make it so redux, you can dispatch other things to redux besides just actions. There's redux promise, where you can dispatch promises.
[00:02:56] There's redux observable where you can dispatch observables written in Netflix, go team. There's also redux thunk where you can dispatch functions. We're going to use redux thunk today, because that is definitely easiest one to use. Thunk is another one of those stupid computer science terms that sounds really complicated and it's way simpler that actually seems.
>> Speaker 2: Another Kyle Simpson gem.
>> Brian Holt: Yeah He's fantastic, you should take his async-
>> Speaker 3: Rehinking asynchronous programming?
>> Brian Holt: It's a fantastic class.
>> Speaker 2: Question, more of an aside. Does Netflix use something like redis or memcached between react and a database?
>> Brian Holt: I'm sure the answer to that question is yes.
[00:03:44] So my team doesn't directly deal with those layers of caching. But there's so many teams at Netflix using so many different ways of caching that I'm sure someone somewhere is using both of those things.
>> Brian Holt: We use a lot of Cassandra specifically for those types of things, but I'm sure we use other things as well.
>> Brian Holt: So let's talk about what a thunk is. I think the best way to talk about thunks is for me to just show you here in the console.
>> Brian Holt: Okay, clear.
>> Brian Holt: Okay, so if I have const dollars = 10, okay? I have const conversionRate = 1.1. I'm making it up.
[00:04:41] I have no idea what the conversion rate right now is for the dollar to the euro. And I say const euros = dollars * conversionRate.
>> Brian Holt: Now I have the value of euros, 11, okay? Pretty straightforward so far. The problem is that with this abstract and pointless example, Is that conversion rate is now set, cuz I made it a const, right, it's 1.1.
[00:05:11] And every time I call that same formula,
>> Brian Holt: Dollars * conversionRate, dollars, we get the same answer, and conversionRate can't fluctuate, right? But let's say I have access to the conversion rate in real time, and I wanna be able to make it update in real time. This abstraction falls apart because I can't modify conversionRate.
[00:05:38] So wouldn't it be great if conversionRate was some sort of thing that could fluctuate along with it? Well I can make conversionRate equal to a function that returns 1.1, right?
>> Brian Holt: Well
>> Brian Holt: Fine, two.
>> Brian Holt: So now I can call dollars * conversionRate2() and invoke that function. So conversionRate2() is just wrapping that value in a function.
[00:06:17] But now, conversionRate2() is this black box that I can modify behind the scenes. Because if that's determined when I call it, it's not determined when I define it. Does that make sense, that very small but important difference, it's where that value is determined. ConversionRate2 is determined when I call the function, whereas conversionRate1 is determined when I created the variable.
[00:06:44] This is a very arbitrary example that doesn't make a ton of sense in devtools, right? Cuz, well, whatever, you can just go back and redefine it right there, right? But my point is is that when it's determined, this is where 1.1 is determined, right? Because this is when that function expression gets called.
[00:07:03] Whereas this one is determined up here when I actually set const conversionRate = 1.1. This is called a thunk. This is a function that kind of represents a value, right. And so, it can get determined, quote unquote, lazily. It can get determined at a later point, as opposed to essentially at compile time.
>> Brian Holt: So that's really all this is. That's all that a thunk is. It's basically just a function that allows you to do things later, instead of now. So giving redux the ability to understand thunks, you're basically saying, hey, I need to determine something later. I don't wanna determine it now.
[00:07:42] And what's great about that is I can make those later things be asynchronous, rather than being now, which is like a synchronous here's your action. I wanna say, okay, here's a function, call the function, and then some time the function is gonna call you back and say something changed.
[00:08:01] If you wanna learn more about thunks and other things like that, I would definitely again suggest the Frontend Masters, Kyle Simpson, course on async.