00:00 So having the ship promise right here and using that ship promise, that works fine and it's really cool. But it would be cooler if the ship details could just accept a ship name and call get ship itself. That way, it can be dynamic. The user can choose which ship they want to see. It's not something that's static at the very start.

00:18 But this is a little bit more complicated than you might think. So let's take this as an example. We've got our number info and we're going to display the user's information in here. Here we have this fetch user. So if we structure things this way, then every time we re-render this component, we're going to be triggering a fetch call.

00:38 That is not great and it doesn't even only matter for if you're managing other state. Like if we didn't have this, then we actually still would have a problem just because when fetch user resolves our number info is going to re-render and fetch user will be called again. So every time our component is re-rendered,

00:58 fetch user is going to be called again. Now, React actually notices this and it will give you a warning telling you what's going on. But yeah, you don't want to have this problem at all. Not a good thing. So how do we solve this problem? We solve it by caching.

01:14 We make fetch user be something that will hang onto the promise so that the next time fetch user is called, we can return the original promise. And we don't end up triggering another fetch. And we can do this a really easy way by declaring a variable outside. And whenever fetch user is called, we're going to say, hey,

01:33 my user promise is equal to itself if it's already defined or a actual fetch call that we're going to implement. And then we can return the user promise. So if it's already been defined, we never end up calling fetch user impl again, impl short for implementation. So that handles that.

01:53 But this is a pretty limited use case. What if we had an ID or something we wanted to accept as a parameter or something? So if we did have that, we could say we have a map and the string is the ID. So and then like the value would be the promise of the user.

02:11 So we have our user promise cache. Our fetch user takes an ID. And if that user already exists in there, then that's what we assign to the user promise. Otherwise, we create a new promise and assign that to the user promise. We stick that in the cache and we return the user promise.

02:28 Then we can have as many of these as we want. Now that's as far as we're going to go as far as caching is concerned in this workshop. The caching deserves its own workshop altogether. And I have this talk caching for cache that you can find on epicweb.dev slash talks

02:45 that will take you through a lot more on what it means to cache stuff and all the difficulties around cache and validation and all of that stuff and caching keys and so much stuff that you can learn in there. That's as far as we're gonna go for cache stuff is just making that simple map.

03:05 Let's also talk about transitions though, because as we're transitioning from one place to another and like fetching a new thing, often it's like our initial load, we wanna show that suspense boundary with the pending UI. But when we're going from one thing to another,

03:24 just updating the UI to something else that suspends, going back to that loading UI can be jarring. Like maybe it's useful, but maybe it's nice to just leave the old stuff while we're waiting for the new stuff. And so with that, we enter into transitions. And so we have this is pending

03:42 that we get from this use transition hook from React. And then we have this start transition. And so when we change some state that's going to trigger a component to suspend, we can start that inside of this transition. And then that will give us an is pending so we can show a more subtle loading state

04:02 to the user while that is happening. And on top of that, in this exercise, we're going to avoid flashes of loading state using a library called spin delay, which will be fun. So this is gonna be a really interesting one, give us a much better user experience as users are using our component here

04:21 for viewing different ships. And we have this quick to re-render so that you can check to make sure that even when it re-renders, it's not triggering a refetch and all of that stuff. So lots of exciting things to look forward to here. I am excited to get into it. So let's do.