Bundling inside of application is now working out pretty well, but there are a couple of odd things
about it.
So we're going to spend the rest of this section going through a couple of very small items.
Each of these might seem really inconsequential, but honestly, it is these extra little attention
to detail items that really make a awesome application.
What we have right now, it definitely works, but there are some really easy improvements we could
add in.
It just takes just a little bit of time to understand each of them.
So let's go over the first very small improvement in this video.
OK, so I'm going to refresh the page here really quickly.
And I just want you to notice some interesting behavior whenever we refresh the preview window initially
is just not there.
And then after a very brief pause in time, we then see it flash very quickly.
So watch this and refresh.
It's not there.
Then a flash.
It's not there.
It comes in, then a flash.
And that's definitely very repeatable.
So let's take a look at a quick diagram and just understand why that is occurring.
OK, so here's what's going on inside of application.
First we refresh the page, our application loads up.
We then dispatch a couple of different actions inside of our students file.
Two of those are creating code cells.
Those actions get processed by our code or excuse me, our cell reducer.
That creates two different code cells that causes our state to update.
That new state is provided to our list component and then eventually we see it to code cells appear
on the screen.
So we're now displaying two different code cell components and inside those code cell components, remember,
we've got that exact function that is this effect right here.
The only goal of this USIE function is to wait for about seven hundred and fifty milliseconds and then
eventually attempt to create a bundle for this particular cell.
So when we show the code cell component, initially we set up a timer to attempt to bundle our code
in seven hundred and fifty milliseconds.
And remember, while we are waiting for this initial bundle, we are not showing the preview window
on the screen at all.
There's nothing there.
Remember, we put in that check inside of our lock down here.
We said if we don't have a bundle, just don't show the preview component.
That explains why we initially do not see the preview window appear for a very small period of time.
It's because we are waiting these seven hundred and fifty milliseconds to do our first initial bundle
attempt.
So here's the problem that wait right there during our initial render of our application is not necessary.
We want to show a user some bundled output as soon as possible when they first load up our application.
We want to show that preview window instantly if we can, and we want to get some bundled code in there
as quick as we possibly can.
So this initial delay around our use affect function and all that bounce logic is just not necessary.
If we are rendering our code cell component for the very first time, we don't want to wait seven hundred
fifty milliseconds.
We want to bundle the user's code right then instantly.
So there's a couple of ways that we could achieve this.
Let's take a look at one or two that are going to seem pretty obvious.
The first thing you might think would be, all right, we want to always attempt to bundle a user's
code instantly.
No problem.
Let's add in a second effect hook.
We could add in a second use effect.
And say that we only want to run this thing one time when our component is first rendered.
So we'd put on empty array right there.
Then inside of your.
We can attempt to create our bundle without any timer or anything like that, so as you probably guessed,
this means as soon as we start to show Kozel greater bundle right away.
And that's it.
We're going to save this.
Look back over to a quick refresh and now we'll see almost instantly the preview window appears.
However, after a brief pause, we still get a second flash of that window.
So although it seems like this might be a reasonable solution, it turns out that this is kind of potentially
even worse than what we had before.
Let's take a look at another diagram and really understand what's happening now.
So everything is going on exactly the same, all these different steps are occurring exactly as they
were before, but now we've just got this extra use effect hook that's going to attempt to bundle a
user's code immediately.
So when we first show code cell, we're going to call that first use effect.
We're going to attempt to bundle the user's code right away.
But then we're also going to bundle their code a second time.
Seven hundred and fifty milliseconds later, because we're still running that second use effect hook.
So this is kind of the worst of both worlds.
We are now attempting to bundle the user's code right away, but we're also doing it again.
Seven hundred and fifty milliseconds later.
This is definitely a very poor solution because remember, a user might eventually have many different
code cells on the screen.
And when they first come to our application, we're now saying that we're going to bundle all those
different cells twice at the very start.
And that just means that, well, that's going be a pretty big performance penalty.
At the end of the day, bundling a user's code is always going to take some good amount of processing
power.
So first thing, we're bundling twice as much as necessary at application startup.
A user is just going to come to our app and think it's a really laggy application because the very first
instant they come to it, we're going to be doing a lot of work.
So we need to think of some way to kind of do something similar, but we don't want to do both Bundall
attempts.
We want to only do a bundle instantly.
And then only attempt to rebundle once a user has actually made a change to a cell.
So let's take a pause right here.
Now that we probably really understand the issue, come back to the next video and take a look at a
possible solution.