If you already have a subscription, you can sign in.
Enjoy free content straight from your inbox 💌
00:00
Modern react comes with a use API that provides a convenient way to effectively await a promise even when you cannot use Async Await. For this example, we will use an external API that calculates the prime factors of a given input number. This API returns a promise and we plan to use it within the prime factors component. Note that this is a client component as indicated by the presence of a used client. What this means is that this component cannot be marked as async, which in turn means that we cannot simply make the API call and await its result.
00:31
So let's take a look at what we would need to do with traditional react. In order to make the API call and load its result, first we create a state variable with use state that will store the result. Once it arrives and initially we set it to null, then we utilize use effect to make that API call. Once a component is mounted. After that API returns with the result. We store it within our state variable, and for this use effect we depend upon the provided input prop. With this API call in place, before we return the final rendering, we first need to check if effect as is null.
01:04
If it is, then we are still waiting for that API to complete and therefore we return a loading screen. And if it is not null, it means that we have received the results and we simply render them out within our user interface. While at this point, we could continue to improve this code, but let's take a break and look at what this application looks like within the browser. Once the component is mounted, it makes that API call. And while that API call is still pending, we see a loading screen and after the API call is complete, we see the final fully rendered ui. There are a few issues with this implementation. First, there is a lot of code
01:37
to effectively only achieve awaiting a promise. Additionally, it locks the loading state into the component, which makes it difficult to consolidate multiple loading states. With the suspense boundary, these are exactly the kinds of problems solved by the use API, which React provides out of the box. We start off with a clean slate and bring in the use API from the core react module. Now, instead of accepting the final result, we accept the promise of the final result within the component, which in our case will be a promise of two numbers. Since we are in a client component,
02:09
we cannot simply await the promise. So instead, we use the use API provided by React. This is effectively the same as await. So we get back the final resolve value and from this point forward we can use it however we want. For example, simply render it within the return user interface. We still have to make the API call in order to create the promise, and we do that in the parent component. This ensures that the API call is made only once, and whenever the client component read ends, we don't end up making another API call. The question you should have at this point is,
02:41
what about our loading state? Well, fortunately, the use integrates with suspense the same way Async await integrated with suspense as we have seen before, which means that if you want to show a loading indicator for this component, we simply wrap it up with suspense providing a fallback. This has the advantages that we have Already covered in our lessons on suspense. For example, we can consolidate multiple loading states into a single coherent experience. Now, let's verify if the application still behaves as it did before, and no surprise we see the loading state while that component is waiting for the API call
03:14
and once it is returned, we see the final fully render ui and there is no doubt that this code is much more declarative and simpler than before. Thanks to use and suspense.