Warning: React 19's use Hook Can Impact App Performance - Çift Dilli Altyazılar
The new use hook in React 19 is awesome.
It's a hook that gives you the functionality of a weight inside of your component.
Let's say you have a fetch inside of a component.
Well, you can't just await that fetch because you can't have async components on the client.
So now, we've got use.
You basically use use instead of a wait.
And think that you could just put the fetch in use and then wrap the component in a suspense and you'd be good.
But you'd be wrong because each time the component is re-rendered,
that fetch will create a new promise and start that process all over again.
Now this used to create, in earlier versions, an loop.
But React 19 now just gives you a warning about an uncached promise and stops the loop.
Now it is a warning but you still shouldn't use it.
The right fix here is to hoist that promise and then pass that promise down into the rendering component inside of the suspense.
Now that's just one issue.
You be aware of when it comes to the use hook.
There are actually two more that I want to show you.
The second one could actually impact your application's performance.
So stick around for that.
Let's get into it.
Alright, so as always, all of the code for this video is in a link in the description right down below.
And I really encourage you in this case to try this out for yourself.
Now the first thing we're going to about is resetting state when it comes to use.
So the director we're going to look at is state resets.
And it basically starts where we left off in the introduction.
We have our app component with that hoisted promise that we then pass on to the name display
inside of a That name display then uses use to get the value from that fetch and then put it in an H1.
Now let's go take a look at name dot Jason name dot Jason has Jack's own in it.
So we should expect when we look at the browser to see Jack's own and in fact
We get a little bit of a loading state there, and then we get Jack's own.
So what am I talking about when it comes to this state reset, when it comes to promises?
Well, imagine, let's go take this name promise.
Let's move it back into name display like this, and get rid of that.
Get rid of this.
Yeah, that should work, right?
I looks good.
So let's save and run.
It refreshed, that looks good.
Let's go take a look at our console.
So as we can see, we're actually getting two requests for name.json, which seems really weird.
Maybe we're in React Strickmo.
Was it good to take a look and see if that's the case?
So over here in our main JSX, we can see that we are not wrapped in strict mode, so we're not in strict mode.
So actually, are we getting this use date run twice?
Well, let's take a look.
So we'll turn our fetch,
and they'll put in a little console login here, and we'll see how many times does this name display one come up.
But it refresh, ooh, it's getting run twice, that's it.
interesting.
So what's actually happening here is that a mode is getting flipped inside of react when it comes to name display.
By default,
a component would be essentially in a like a synchronous mode and then at the point of which you use React,
then flips the switch, resets all of the state inside of that component, and then starts again with a new render with all new state.
Now I can demonstrate that this is the case by adding more U-state send.
So let's go and take this U-state,
and I'll get rid of the fetch, and call this name display 2, and then I'll add another U's, and name display 3.
And what would you expect to see?
So going to see name display one twice.
That's what we saw before.
Now that we're the case that every single use would reset the whole system,
then we would expect to see name display twice, and then maybe name display three once.
So let's see what we actually see.
Now we see as we expect that names play one twice as we expect,
but two and three,
because we've now switched into an asynchronous mode are only done once, which is kind of what we expect from a use state initiative.
So that's why I say we're kind of switching into a mode here.
That first name display is actually kind of in synchronous mode,
then we hit that use,
we then get a state reset,
and then we go into an async mode and now one, two, and three, those subsequent console logs are all in now an asynchronous mode.
Now it's strongly recommended not depending on this behavior,
either being there or not being there,
just write your components the way that you would expect to write your components in a logical way and make sure that if that use state initially.
memo initializer gets run multiple times, but it's not going to be a problem for you.
Now, this state resetting behavior when it comes to use is actually a little bit more subtle even still.
Let's go take a look at this lazy use example.
Now, one of the interesting things about the use look is that you can actually conditionally use use.
You can't conditionally use any other hook.
You can't conditionally use a use date or a use memo.
You always have to have the same number of use dates or use memos or use callbacks inside of your component.
But use, you can actually optionally use it.
So in our app component,
we've wrapped this well-named suspended optional value display component in a suspense, suspended optional value display is we're really doing.
we've got this enabled flag that we then cargo with a button.
And then only when enable is true, do we then use a use hook to actually get an async value?
So it's an async promise, but it doesn't really take a long time.
We still need to use use to actually access that value.
and it works, right?
So we hit toggle, that enabling goes to true.
So do we actually get that state reset behavior?
Well, let's go and add a console log in here and see what happens.
So I'll put it in a console log and it tells us how many times we're actually using that use state.
So one would expect that when I hit this toggle
that we would reset that state if it followed the same semantics as we had before.
But what I think is happening here is that mode flip
only happens if you have not completely rendered the component before you use that first use.
In this case,
the first time we go through enable this false,
we render the component,
we render the button,
we render the div and then only after the component has rendered
do we then allow the toggling of that enable flag
which then subsequently brings in that lazy use and that's okay because the component has already been rendered.
So we don't get that state reset.
In the previous example, when the component had not yet been fully rendered.
Okay, now let's talk about performance when it comes to use.
So we're going to look in our staggered directory and take a look at that example.
So I'll run that, and now I'll hit refresh.
And now we can see it's taking a long time to render.
In fact, it's.
seven seconds to render because we are sequentially doing all these promises.
The first promise is done in a second,
second is done in two seconds,
and third is done in three seconds, and we're doing them sequentially, which means that the total time to render the component is seven seconds.
And that's not good.
Let's go take a look at the So up at the top here, we have a helper function called time promise.
It just returns a promise that times out after that number of seconds that you give it with that value.
And the component we're looking at is sequential promises.
Now there is some performance bracketing code here,
the sequential render start,
we just set it when we first render,
and then we put it got a console log, we finally get to the console log at the end.
Again, use a similar to await.
So we're not gonna get to line 20 until we've completely gone through all of those uses.
So what's actually happening here is because we've got this staggered set of U states where
we've got the short promise and then we await it,
we've got the medium promise creation and then we await it and the long promise creation and then we await it, we're getting this waterfall.
So because U stops the execution of the function in its tracks,
we don't actually start on the medium promise until the short promise is completely resolved.
So we get this sequential waterfall effect.
Get a second.
And then after that second,
we started the two seconds, and then after the two seconds, we started the three seconds, and all sum up, that's six seconds of delay.
So why are we seeing seven seconds?
Well, we're seeing seven seconds because of that state reset.
That first used state is creating the promise, which is then used.
Well, we know that with that state reset, we get run twice, and so we're getting that first promise twice to avoid that.
that, we can create a simple static promise that resolves immediately, and then just use that ahead of everything else.
Now let's take a look.
And now we get six seconds instead of seven seconds, because we're not duplicating that first time promise.
All right, but we don't to do things in sequence.
We to do them parallel.
So how Once we go down here and in the app we'll bring in the parallel local promise component,
take away our sequential promises and we'll try that out.
So now we're running these promises in parallel,
and we're reading four seconds instead of six,
but really we'd like to see three seconds,
because the long pole here is the done in three seconds promised, so we'd like to see three seconds.
So what's actually happening?
So we look at our parallel local promises.
What done is we've moved all of those U States from being interleaved with the U's up to being ahead of the U's.
So that's why we're getting the parallel behavior.
We're starting all those promises simultaneously,
but we are getting stuck with the state reset
because we're creating the promises inside of the component and we're resetting all of the state when that first U's finally unlocks,
which would be the first second.
So we're getting an extra second in there.
To avoid that, we could again use that fake static promise.
And we'll run it again, and we get the 3-second ideal.
But what we really should do is hoist it.
So let's go and take a at the hoisted variant.
So this component is called sequential hoisted promises and that's because we've hoisted the promises up into our app and now
We're passing them down as props into our sequential hoisted promises
component Go take a look at the implementation on this
So now you take our promises as props and we use them inside of our component This looks really clean.
Let's see outperforms And there you go,
that's the ideal,
and there's none of this hackery trying to get around the state reset because we don't have any state inside of this component to reset either
way.
But I got to say from a code perspective,
having all of those uses kind of as their own use, I don't know, maybe that's not something I'd want to do.
Is there an alternative?
Yeah, sure.
You could use promise.all.
So For an example, I'll uncomment out the PromiseAll example, and we'll take a look.
So let's save and see how it goes.
All right, so getting the ideal for three seconds.
Let's take a look at our So here we're creating local state called promise group.
That promise group is just a promise dot all, promise dot all takes an array of promises, and then we use that promise group.
And the nice thing about promise dot all is that you get back
the results of those promises in the order that you had them in the original array.
So a short promise comes in as the first one, medium the second, long the third.
Cool.
So what about the state reset?
Why don't we actually,
12 seconds or whatever the worst case scenario here is,
well, promised at all is just returning very quickly a promise back that depends on these other promises.
Those other promises are already in flight.
So even though we are getting that state reset, we're returning a promise that is dependent on the other promises.
So it really doesn't matter in this case that we're actually creating two promises.
Although I would say maybe this isn't the right thing to do.
Maybe you would then hoist that promise out all up, but it's really up to you.
I think this is kind of one of the things that you need to expect.
All right.
Well, I know this is another one of those in the weeds videos.
Some love them.
Some folks don't.
But do think that as we get into React 19 and React 20,
we're going to be seeing a lot more of suspense and use and understanding its behavior in a deep way is really important.
So I really encourage you to actually jump into this code,
try it out for yourself, and see if you can completely wrap your brain around the behavior that's going on here.
If content like this, I am working on pronextjs.dev.
That's my course where we dig into basic and really advanced topics around next-js.
there are two free tutorials that you get access to if you sign up for the newsletter,
there's one on state management,
another on forms management,
those are really sticky topics and they're good to know and the tutorials are free, so you should try that out today.
In meantime,
of if you like this video,
hit that like button and if you really like the video,
hit the subscribe button and click on that bell and you'll be notified next time new.
Blue coder comes out.
Çeviri Dili
Seç
Daha Fazla Özelliği Açın
Trancy uzantısını yükleyerek, AI altyazılar, AI kelime tanımları, AI dilbilgisi analizi, AI konuşma vb. dahil olmak üzere daha fazla özelliği açabilirsiniz.
Büyük Video Platformlarıyla Uyumlu
Trancy, YouTube, Netflix, Udemy, Disney+, TED, edX, Kehan, Coursera gibi platformlar için çift dilli altyazı desteği sağlamakla kalmaz, aynı zamanda düzenli web sayfaları için AI kelime/cümle çevirisi, tam metin etkileşimli çeviri ve diğer özellikler sunar. Gerçek bir çok yönlü dil öğrenme asistanıdır.
Tüm Platform Tarayıcıları
Trancy, iOS Safari tarayıcı uzantısı dahil olmak üzere tüm platform tarayıcılarını destekler.
Çoklu Görüntüleme Modları
Tiyatro, okuma, karışık ve diğer görüntüleme modlarını destekleyerek kapsamlı bir çift dilli deneyim sunar.
Çoklu Uygulama Modları
Cümle dikte, sözlü değerlendirme, çoktan seçmeli, dikte ve diğer uygulama modlarını destekler.
AI Video Özeti
Videoları özetlemek ve hızlı bir şekilde temel içeriği kavramak için OpenAI kullanın.
AI Altyazılar
Sadece 3-5 dakikada doğru ve hızlı YouTube AI altyazıları oluşturun.
AI Kelime Tanımları
Altyazılardaki kelimelere dokunarak, AI destekli tanımlarıyla kelime anlamlarını öğrenin.
AI Dilbilgisi Analizi
Cümle dilbilgisini analiz ederek cümle anlamlarını hızlıca anlayın ve zor dilbilgisi konularını öğrenin.
Daha Fazla Web Özelliği
Çift dilli video altyazılarının yanı sıra, Trancy ayrıca web sayfaları için kelime çevirisi ve tam metin çevirisi sağlar.