1
00:00:00,830 --> 00:00:05,720
I would like to make sure that if a user writes out some code right here, we do not just suddenly flash

2
00:00:05,720 --> 00:00:10,340
in that progress bar and then just immediately remove it because it's just visually very distracting

3
00:00:10,340 --> 00:00:11,440
and doesn't really look that great.

4
00:00:12,170 --> 00:00:16,370
So we need to figure out some way to kind of put together a set of rules of when we want to show the

5
00:00:16,370 --> 00:00:17,960
progress bar and when to hide it.

6
00:00:18,590 --> 00:00:22,760
And the root issue here is that you and I cannot very easily predict how long it's going to take to

7
00:00:22,760 --> 00:00:23,870
bundle a user's code.

8
00:00:24,380 --> 00:00:27,460
We don't really have any insight into what it's billed as doing per say.

9
00:00:27,680 --> 00:00:32,420
And if a user starts to import some kind of module that we have never cashed before, we don't really

10
00:00:32,420 --> 00:00:35,420
know how many files in total we need to fetch from Unpackaged.

11
00:00:35,660 --> 00:00:41,300
Because remember, as we download each file and process it, we might get another number of imports

12
00:00:41,300 --> 00:00:42,110
inside that file.

13
00:00:42,560 --> 00:00:47,510
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.

14
00:00:48,050 --> 00:00:50,180
But there are a couple of assumptions we can make.

15
00:00:50,900 --> 00:00:55,520
The first assumption we can make is that if a user is only writing out some plain JavaScript code and

16
00:00:55,520 --> 00:01:00,260
there's no import statement inside of it, then it's probably going to be a very fast bundle.

17
00:01:00,270 --> 00:01:02,540
It'll probably take just a fraction of a second.

18
00:01:03,520 --> 00:01:08,800
Second, if user ever adds any import statements, especially an import statement for a module that

19
00:01:08,800 --> 00:01:13,870
we've never fetched before, it's very possible that it might take a lot longer to put the bundled together,

20
00:01:14,020 --> 00:01:18,580
because that means that we might have to go off to unpackaged and fetch a ton of different files to

21
00:01:18,580 --> 00:01:19,480
assemble the bundle.

22
00:01:20,340 --> 00:01:25,020
So our first option might be to take a look at the users code and say how many important statements

23
00:01:25,020 --> 00:01:27,330
are there and if there is an import statement?

24
00:01:27,360 --> 00:01:28,470
Have we ever cashed it?

25
00:01:29,800 --> 00:01:34,240
If we have an import statement for a module we have not cached, that might be a sign that this will

26
00:01:34,240 --> 00:01:37,550
be a long Bundall attempt and we might want to show the progress bar.

27
00:01:38,320 --> 00:01:39,810
So that's definitely one thing we could do.

28
00:01:40,000 --> 00:01:43,690
But at the end of the day, there's actually a little bit easier alternative.

29
00:01:44,170 --> 00:01:49,330
This is kind of a little trick and it doesn't always work out as expected, but it generally works out

30
00:01:49,330 --> 00:01:50,310
kind of OK.

31
00:01:50,980 --> 00:01:55,000
You might notice that when we ever we'd write out some very simple code inside the editor, the bundling

32
00:01:55,000 --> 00:01:58,750
process occurs extremely quickly, like just very, very fast.

33
00:01:59,540 --> 00:02:01,930
So we can put together or just make a little assumption.

34
00:02:01,960 --> 00:02:08,139
We might say that if it ever takes longer than a little fraction of a second to assemble a user's bundle,

35
00:02:08,440 --> 00:02:11,080
then chances are we'll just make an assumption.

36
00:02:11,230 --> 00:02:15,130
We can assume that we are probably fetching some files from Unpackaged.

37
00:02:16,070 --> 00:02:20,480
And in that scenario, well, chances are it's going to take longer than point two seconds.

38
00:02:20,950 --> 00:02:22,750
Now, the point, two seconds is totally made up.

39
00:02:22,760 --> 00:02:24,590
I'm just making a total guess here.

40
00:02:24,830 --> 00:02:29,270
And obviously that point two seconds can vary based upon the power of user's machine and the speed of

41
00:02:29,270 --> 00:02:30,230
their Internet connection.

42
00:02:30,540 --> 00:02:35,480
But in general, we can just say, you know what, if it takes any longer than point two seconds, chances

43
00:02:35,480 --> 00:02:40,450
are the user might be bundling some code and we should probably show a progress bar in that scenario.

44
00:02:41,120 --> 00:02:46,640
But if it's ever less than point two seconds, then chances are or in the span of zero to point two

45
00:02:46,640 --> 00:02:51,200
seconds, we can just assume that the bundle might be done very, very quickly and we shouldn't show

46
00:02:51,200 --> 00:02:51,980
a progress bar.

47
00:02:53,250 --> 00:02:55,170
So what does this actually mean, what am I trying to say?

48
00:02:55,350 --> 00:03:00,750
Well, rather than trying to put together some really complicated JavaScript to try to estimate how

49
00:03:00,750 --> 00:03:05,400
long it's going to take to do a bundling attempt, we're going to instead just write out some relatively

50
00:03:05,400 --> 00:03:06,600
simple success.

51
00:03:08,000 --> 00:03:13,160
So what we are going to do, we're going to apply a little time to animation, to the progress bar that

52
00:03:13,160 --> 00:03:18,950
we show right there, whenever we show the progress bar, we are going to gradually change the capacity

53
00:03:18,980 --> 00:03:21,500
of the progress bar and feed it in over time.

54
00:03:22,100 --> 00:03:25,370
So we're going to just very gently, very slowly fade it in.

55
00:03:25,670 --> 00:03:30,110
And that's going to kind of take this rule into account and say, OK, well, the longer that we go

56
00:03:30,110 --> 00:03:34,220
on, the more likely it is that this is going to be a long bundling attempt.

57
00:03:34,430 --> 00:03:36,560
So we do want to show that progress bar.

58
00:03:37,610 --> 00:03:42,830
So I know this description right here is not the most effective, so the best thing to do is to take

59
00:03:42,830 --> 00:03:47,660
a very quick break, come back to next video and try to put a little bit of a transition or animation

60
00:03:47,660 --> 00:03:48,110
together.

61
00:03:48,350 --> 00:03:53,360
And I think we'll see very quickly that this assumption actually works out pretty well in a good number

62
00:03:53,360 --> 00:03:54,080
of cases.