This course has been updated! We now recommend you take the State Management with Redux & MobX course.

Check out a free preview of the full Advanced State Management in React (feat. Redux and MobX) course:
The "Thunk Tradeoffs" Lesson is part of the full, Advanced State Management in React (feat. Redux and MobX) course featured in this preview video. Here's what you'd learn in this lesson:

Discuss tradeoffs with testing and debugging asynchonous code.

Get Unlimited Access Now

Transcript from the "Thunk Tradeoffs" Lesson

>> Steve Kinney: And we're gonna get to talking about my favorite thing in computers which is trade-offs, right? There is a certain simplicity to a tongue, that makes sense in our cases. But they're not pure, that's what we talked about before, they have side effects and the further your code gets away from being like a pure function, where you put in inputs and you get outputs, the harder things are to test, right?

[00:00:33] If a piece of your code involves something this happening to be globally in scope, you need to now simulate that in your tests, right? Which depending on what it is can be really difficult if it does have a side effect or if it is talking to the network in this case, you need to mock that out, right?

[00:00:51] That can all be slightly difficult, it's not super difficult so here's like a test that you could use for a thunk. There is a library called fetchMock, if we're trying to actually fetch from a server, we can mock it out with a response. And then that would resolve the thunk and we would dispatch and everything would be gravy, and it's all good, right?

[00:01:14] But that is less simple than the tests you saw when you were implementing Redux earlier and there were just object goes in a function, something comes out, right? It is definitely a little bit more difficult than that, and like this overhead starts to weigh on you. So it would be great if we could dispatch something from the database, right, and that's it, we're dispatching action.

[00:01:40] Something sits in the middle, handles all that, dispatches another action that changes the UI, it would be great if we could get in the middle. But a lot of times, the way to make something easier is to give yourself a good hook somewhere in the middle of the process that you don't previously have.

[00:01:53] So we dispatched an action, whatever other stuff goes on, we can wait for that to happen and then we dispatch. And actually we can say like hey, did the button, that you click, did that dispatch? And you are like tongue or item, action? Like right now it's going to dispatch a tongue which will eventually dispatch an action, but how did you know that clicking the button did the thing you wanted?

[00:02:12] You don't, right? Unless you do the entire process of mocking out the server, waiting for the server to respond, getting back the action that was dispatched through the thunk. Like you have to wait for all of this when you just wanna know hey, the user, if they touched this button I just wanna know, did this action fire, right?

[00:02:30] So we need some way to get in there, right? We need to figure out the information that's going before the A sync and information after the A sync.