Revalidation Optimization Exercise

[00:00:00]
>> Let me introduce Exercise 4, so we can get going on that one. We're going to go through this rigmarole again, we go and open up the readme, close down the server for Exercise 3 and start node dev 4, go over to the app to port 4004. Login with kotty@remix.run and Kotty loves you and you should be back at the app.

[00:00:29]
For this one, we're going to be using an unstable API. Hmm. We can talk a little bit about that after the exercise, but we're optimizing for revalidation. So, anytime there's any form submitted, any mutation, Remix decides to do what the web does and say, all bets are off on this stuff, let me go get the new HTML.

[00:00:49]
In the case of Remix, we're just doing fetches, so we're not getting all the new HTML. We're just going to re-fetch all the data and re-render components. So, there are situations where you may be building something where you're like, I actually don't wanna go get all the data because I've got lots of data here and that would just be suboptimal.

[00:01:07]
So, Remix starts with the thing that's correct and then you can optimize to make that correct thing a little more optimized for your specific use case. And so this is one of the hooks, not to be confused with React Hooks because it's not reactive, but it's one of the ways you can hook into Remix to help configure that a little bit.

[00:01:26]
So, you've got a little bit of background around that you can take a look at this. The API you're gonna be using is unstable, shouldReload. So, it is unstable prefixed. We are confident on the use case, just not 100% sure on the specific API. So, the API could change, and that's why it's unstable prefix.

[00:01:46]
And there's also potentially bugs with that because not a lot of people use this API yet. So ,I believe we should be good though today [LAUGH], hopefully. So yeah, have a good time with Exercise 4 with Unstable_shouldReload.