I would like to make sure that if a user writes out some code right here, we do not just suddenly flash
in that progress bar and then just immediately remove it because it's just visually very distracting
and doesn't really look that great.
So we need to figure out some way to kind of put together a set of rules of when we want to show the
progress bar and when to hide it.
And the root issue here is that you and I cannot very easily predict how long it's going to take to
bundle a user's code.
We don't really have any insight into what it's billed as doing per say.
And if a user starts to import some kind of module that we have never cashed before, we don't really
know how many files in total we need to fetch from Unpackaged.
Because remember, as we download each file and process it, we might get another number of imports
inside that file.
So we really just have no idea at the on the day how long it is going to take to bundle a user's code.
But there are a couple of assumptions we can make.
The first assumption we can make is that if a user is only writing out some plain JavaScript code and
there's no import statement inside of it, then it's probably going to be a very fast bundle.
It'll probably take just a fraction of a second.
Second, if user ever adds any import statements, especially an import statement for a module that
we've never fetched before, it's very possible that it might take a lot longer to put the bundled together,
because that means that we might have to go off to unpackaged and fetch a ton of different files to
assemble the bundle.
So our first option might be to take a look at the users code and say how many important statements
are there and if there is an import statement?
Have we ever cashed it?
If we have an import statement for a module we have not cached, that might be a sign that this will
be a long Bundall attempt and we might want to show the progress bar.
So that's definitely one thing we could do.
But at the end of the day, there's actually a little bit easier alternative.
This is kind of a little trick and it doesn't always work out as expected, but it generally works out
kind of OK.
You might notice that when we ever we'd write out some very simple code inside the editor, the bundling
process occurs extremely quickly, like just very, very fast.
So we can put together or just make a little assumption.
We might say that if it ever takes longer than a little fraction of a second to assemble a user's bundle,
then chances are we'll just make an assumption.
We can assume that we are probably fetching some files from Unpackaged.
And in that scenario, well, chances are it's going to take longer than point two seconds.
Now, the point, two seconds is totally made up.
I'm just making a total guess here.
And obviously that point two seconds can vary based upon the power of user's machine and the speed of
their Internet connection.
But in general, we can just say, you know what, if it takes any longer than point two seconds, chances
are the user might be bundling some code and we should probably show a progress bar in that scenario.
But if it's ever less than point two seconds, then chances are or in the span of zero to point two
seconds, we can just assume that the bundle might be done very, very quickly and we shouldn't show
a progress bar.
So what does this actually mean, what am I trying to say?
Well, rather than trying to put together some really complicated JavaScript to try to estimate how
long it's going to take to do a bundling attempt, we're going to instead just write out some relatively
simple success.
So what we are going to do, we're going to apply a little time to animation, to the progress bar that
we show right there, whenever we show the progress bar, we are going to gradually change the capacity
of the progress bar and feed it in over time.
So we're going to just very gently, very slowly fade it in.
And that's going to kind of take this rule into account and say, OK, well, the longer that we go
on, the more likely it is that this is going to be a long bundling attempt.
So we do want to show that progress bar.
So I know this description right here is not the most effective, so the best thing to do is to take
a very quick break, come back to next video and try to put a little bit of a transition or animation
together.
And I think we'll see very quickly that this assumption actually works out pretty well in a good number
of cases.