Promise Cache

[00:00] We've got three loads of the ship every time we load a ship. That is not cool. The way that this is working is we've got these ship buttons right here. Whenever one of those has changed, we set the ship name that changes the state which was initialized to dreadnought, and that ship name is then passed down to our ship details,

[00:18] which is wrapped around our error and suspense boundaries. If we dive into ship details, we'll see it's using that ship name to use get ship, to use the promise that's returned from get ship. This is the utility function that we need to memoize,

[00:35] I guess, to cache for the promise. Let's come in here and we're going to call this get ship impl. The specific implementation here is not all that important for what we're doing. It's just the implementation and here is the input that is dynamic across different renders and stuff. We're going to do that,

[00:54] remove the export because we're not going to export that anymore. Instead, we're going to export a function called get ship. That get ship is going to take the name, which will be a string, and also, sure, we'll want to do the delay so that we can forward it along to the ship impl.

[01:12] Then we're going to check the ship cache. Let's make our ship cache first. Ship cache is a new map where the string here, it will be the ship name and the promise resolves to a ship. Then we are going to make our ship promise.

[01:30] Promise is equal to the ship cache or calling get ship impl with the name and the delay. If it doesn't exist in the cache already, then we'll trigger the fetch request and get the promise from that. Then we'll update the ship cache to set

[01:47] the name property to be assigned to the ship promise, and then return the ship promise. Now, I know somebody is going to ask, so I've got to add it in here. Some of you are going to be like, hey Kent, if it's already in the ship cache, then setting it in the ship cache again, isn't that suboptimal? Yeah, probably yes, but I would be

[02:07] surprised if that ever becomes a bottleneck of any application ever. You could refactor this a little bit to say, hey, check the cache first and if it's in there, then don't bother setting it in the ship cache again or whatever. I don't know, maybe that would be slower. You should profile it and then tell me. But this works really well.

[02:25] Now with that, would you look at that? Only one call of getShip, and we're not going to get this warning. Hold on, what is this? I know what's going on. I actually have async on here, so getShip is returning a promise, and so we're creating that promise every time.

[02:42] We may not be calling the fetch request every single time, but we are definitely creating a new promise and it resolves instantly. Get rid of the async on there. There we go. So now we're not getting the warning and we're not calling getShip every single time or three times when we load

[03:00] the page or when we choose between these different ships. You might also notice that now we're not calling it anymore because we still have a promise for each one of these. So that is interesting. As we increment and stuff, we're not going to see the loading states. So this is where we get into caching questions like,

[03:17] so what if this data is out of date now? How do we update that and things? That again is outside of the scope of this workshop. That would be a whole other workshop by itself. So we're good with just saying we're going to cache it forever as long as the user is on the page.

[03:34] But yeah, you definitely want to think about that in a real application. How do we manage the cache and validation of this stuff? Again, we're doing lower level framework level stuff, typically in a real application you're going to be using a framework that will do lots of this stuff for you already. But it's good and important for you to

[03:53] understand how it works under the hood. So there you go. This is caching our promise so that we aren't triggering a fetch call every single render, but instead we just hang on to the previous promise that was generated when the component was initially rendered. Good job.

[00:00] You'll notice as soon as we land on this page, we're going to get this warning from React. It's saying, a component was suspended by an uncached promise. Creating promises inside a client component or hook is not yet supported except via a suspense compatible library or framework. Well, we're going to be building our own little suspense

[00:16] compatible library for creating promises during render, but we're actually not creating promises during render, and this is a bit of a misnomer because I don't think anybody else is. Well, we're creating one promise during render but then caching it. So I guess, yeah, that warning works. That's okay, React.

[00:35] So we are getting this error, and it's because now we are accepting the ship name into this component and it's suspending, and it has to call GetShip with that ship name so that it can go retrieve that ship. So every time this component re-renders, it's going to go trigger another request for that ship.

[00:53] So if we take a look at this and look at GetShip, boom, we call that three times. Good grief. No thanks. If we change between all of these, look at all those times we're calling GetShip. We should have only called it twice by now, but we've called it six times. Goodness gracious. So yeah, this is a problem, not optimal,

[01:12] and in addition, it's not just when we change the ship. Look at this. If I re-render anything else, we're going to call it three more times. What a joke. Yeah, you're better than this, and so am I. So we're going to do better by caching. So you're going to create a cache for our ship. You'll create a special implementation.

[01:31] So that is the actual implementation, and then you'll have the exposed function will be leveraging the cache. So it'll look pretty similar to this. That is your job in the utils file. Good luck.

Suspense is key to managing async operations declaratively in React. 

It allows you to handle loading states, errors, and other async dependencies more smoothly by rendering a fallback while a promise is pending. 

In this workshop, you'll learn how to:

- Manage loading and errors with Suspense
- Cache promises and use the `useTransition` hook
- Update UI optimistically with `useOptimistic`
- Load images asynchronously with suspense 
- Keep UI responsive with `useDeferredValue`
- Optimize and avoid network waterfalls

Once you're through this workshop you'll have a solid handle on Suspense, which will really improve the UX of your apps and open doors to more advanced patterns in later workshops. 

## Data Fetching

No matter how fast your server is, you need to think about what the user's looking at while they wait. You also need to think about what happens if the request fails.

In this section you'll learn how to manage both of these declaratively in components using `Suspense` and `ErrorBoundary`.

## Dynamic Promises


Here you'll learn how to cache your promises in order to avoid unnecessary re-fetching. 

You'll also learn about transitions and how to make the transition from loading to resolved state smoother using the useTransition hook.


## Optimistic UI

The idea of "Optimistic UI" is based on the belief that most of the time the things your users do will be successful.

In this section you'll discover the useOptimistic hook, which is like useState that actually changes the UI even while it's suspended. 

## Suspense img

Anything async can be suspended, including images! 

This technique involves loading images with promises and using the browser’s native caching system. 

By combining async image loading with Suspense boundaries, you can control rendering fallbacks and ensure images are fully loaded before displaying updated content, avoiding stale UI states

## Responsive

You can run into some problems when using useTransition. For example, if the user is typing in a search box which you're controlling with state, you want to keep the `<input />`'s value up-to-date with what they're typing, not with the previous state while React is waiting for the transition to complete.

So in this section you'll learn how to use the useDeferredValue hook to  display some pending state while also allowing us to display the state that triggered a component to suspend.

## Optimizations

This section is about how to go chasing waterfalls.

Due to the design of Suspense, you can easily create network waterfalls by mistake. 

So what you're really be learning is how to deal with this both on the frontend and the backend. On the front you'll figure out how to trigger requests before use is called. And on the back you'll set cache headers on your responses to tell the client how to cache properly.

Learn how Suspense works under the hood, preparing you for the future of asynchronous state management.

React Suspense

React Suspense

Transcript

Promise Cache

Transcript