1
00:00:01,349 --> 00:00:03,069
As we saw in the last clip, one way to

2
00:00:03,069 --> 00:00:05,041
solve the race condition problem is to use

3
00:00:05,041 --> 00:00:08,069
callbacks and functions inside of other

4
00:00:08,069 --> 00:00:09,768
functions. While solving this one problem,

5
00:00:09,768 --> 00:00:11,995
we've introduced another problem, the

6
00:00:11,995 --> 00:00:14,654
callback pyramid of doom. According to

7
00:00:14,654 --> 00:00:17,659
Wikipedia, a callback pyramid of doom is a

8
00:00:17,659 --> 00:00:19,989
common problem that arises when a program

9
00:00:19,989 --> 00:00:22,656
uses many levels of nested indentation to

10
00:00:22,656 --> 00:00:25,830
control access to a function. But why is

11
00:00:25,830 --> 00:00:27,634
it called the callback pyramid of doom?

12
00:00:27,634 --> 00:00:29,439
Well, let's start by looking at a

13
00:00:29,439 --> 00:00:31,702
simplified example. The code on the screen

14
00:00:31,702 --> 00:00:33,597
is example of code that could be called a

15
00:00:33,597 --> 00:00:36,168
pyramid of doom. It gets this name from

16
00:00:36,168 --> 00:00:38,794
the indentation on the left. If you tilt

17
00:00:38,794 --> 00:00:41,130
your head just right, it looks like a

18
00:00:41,130 --> 00:00:42,825
pyramid. This is the type of code that you

19
00:00:42,825 --> 00:00:44,421
might see in JavaScript when you need to

20
00:00:44,421 --> 00:00:47,230
make sure that A runs before B, and B runs

21
00:00:47,230 --> 00:00:52,482
before C, and C runs before D. But, what

22
00:00:52,482 --> 00:00:54,607
makes this a pyramid of doom and not just

23
00:00:54,607 --> 00:00:58,082
a pyramid? That is, why is this bad? The

24
00:00:58,082 --> 00:00:59,881
first reason is that it makes dirtier

25
00:00:59,881 --> 00:01:02,588
code, and exposes you to more errors.

26
00:01:02,588 --> 00:01:04,269
Let's revisit the code from earlier in the

27
00:01:04,269 --> 00:01:08,567
module with a slight tweak. This time,

28
00:01:08,567 --> 00:01:10,743
instead of just getting two pieces of data

29
00:01:10,743 --> 00:01:13,516
from the API, it's getting four, and each

30
00:01:13,516 --> 00:01:17,105
one is nested inside of the previous one.

31
00:01:17,105 --> 00:01:19,038
There's a lot going on here. Even though

32
00:01:19,038 --> 00:01:21,295
most of it's similar, you still need to

33
00:01:21,295 --> 00:01:23,157
process what's happening every time you

34
00:01:23,157 --> 00:01:25,699
read it, and in fact, there's actually a

35
00:01:25,699 --> 00:01:29,839
bug in this code. Did you see it? Inside

36
00:01:29,839 --> 00:01:32,254
the xhr3.onload function, instead of

37
00:01:32,254 --> 00:01:34,721
parsing the results that came back, you're

38
00:01:34,721 --> 00:01:37,911
parsing the results that came back on

39
00:01:37,911 --> 00:01:40,000
xhr2. It's a simple mistake to be sure,

40
00:01:40,000 --> 00:01:41,433
and it's one that when you see it in your

41
00:01:41,433 --> 00:01:43,378
code you'd likely chide yourself for being

42
00:01:43,378 --> 00:01:46,782
so careless, but it's also a common

43
00:01:46,782 --> 00:01:49,064
mistake. In fact, in preparation for this

44
00:01:49,064 --> 00:01:51,222
course, I did this exact thing in some of

45
00:01:51,222 --> 00:01:54,346
the sample code. Don't worry though, I

46
00:01:54,346 --> 00:01:55,954
fixed it so that you won't be seeing this

47
00:01:55,954 --> 00:01:59,546
error again in this course. Another

48
00:01:59,546 --> 00:02:01,582
problem with pyramiding code like this is

49
00:02:01,582 --> 00:02:04,937
how do you handle errors? If xhr3 returned

50
00:02:04,937 --> 00:02:07,310
[00:06: 33.239 ] a 500 from the server,

51
00:02:07,310 --> 00:02:09,426
then xhr4 wouldn't be called, and the one

52
00:02:09,426 --> 00:02:11,803
error function of xhr3 would get called,

53
00:02:11,803 --> 00:02:15,266
but it's inside the onload of xhr2, so,

54
00:02:15,266 --> 00:02:18,050
what would happen? If you said you should

55
00:02:18,050 --> 00:02:19,958
handle the onerror case, you're right,

56
00:02:19,958 --> 00:02:23,148
but, that can make your code even messier

57
00:02:23,148 --> 00:02:25,623
now. You now have a lot more code in your

58
00:02:25,623 --> 00:02:27,099
onload functions, and you're making the

59
00:02:27,099 --> 00:02:30,051
first problem even worse, but, beyond

60
00:02:30,051 --> 00:02:33,168
that, xhr2 and xhr1 calls were successful,

61
00:02:33,168 --> 00:02:36,142
so, their onerror functions aren't called,

62
00:02:36,142 --> 00:02:37,647
and now you're handling errors inside of a

63
00:02:37,647 --> 00:02:39,493
success function, which can lead to

64
00:02:39,493 --> 00:02:41,600
another series of messy decisions in how

65
00:02:41,600 --> 00:02:44,611
you write your code. So, how can we solve

66
00:02:44,611 --> 00:02:47,472
this problem without introducing a new

67
00:02:47,472 --> 00:02:49,571
problem? How can we write code so that it

68
00:02:49,571 --> 00:02:55,000
executes in order without massive nesting of functions? We'll learn how, next.

