1
00:00:00,000 --> 00:00:02,949
Newcomers to JavaScript often struggle

2
00:00:02,949 --> 00:00:05,902
with its asynchronous nature, particularly

3
00:00:05,902 --> 00:00:08,193
if they're coming from another programming

4
00:00:08,193 --> 00:00:10,933
language that doesn't have callbacks. The

5
00:00:10,933 --> 00:00:12,696
struggle is intensified when they hear

6
00:00:12,696 --> 00:00:14,588
about promises, because they're told that

7
00:00:14,588 --> 00:00:17,579
promises make things better, but they're

8
00:00:17,579 --> 00:00:19,728
not necessarily simple. Before digging

9
00:00:19,728 --> 00:00:22,178
into how promises can help, let's take a

10
00:00:22,178 --> 00:00:24,259
minute to look at a fairly common problem,

11
00:00:24,259 --> 00:00:27,379
fetching data, and how the fact that it's

12
00:00:27,379 --> 00:00:29,705
asynchronous throws a wrench into the

13
00:00:29,705 --> 00:00:32,043
whole system. The code you see on the

14
00:00:32,043 --> 00:00:34,840
screen makes two separate HTTP requests.

15
00:00:34,840 --> 00:00:36,690
This block of code might not be something

16
00:00:36,690 --> 00:00:39,059
you see every day, so let's take a second

17
00:00:39,059 --> 00:00:42,926
to walk through the highpoints. It starts

18
00:00:42,926 --> 00:00:46,675
by creating a new XMLHttpRequest, this

19
00:00:46,675 --> 00:00:48,623
object allows us to make requests against

20
00:00:48,623 --> 00:00:52,285
an API. It specifies the path of the

21
00:00:52,285 --> 00:00:55,773
request in the open function, it then has

22
00:00:55,773 --> 00:00:58,709
an onload function that you can think of

23
00:00:58,709 --> 00:01:01,829
as success. Finally, it has a send

24
00:01:01,829 --> 00:01:04,217
function, that is the entire block is set

25
00:01:04,217 --> 00:01:07,394
up, and then the request is actually sent.

26
00:01:07,394 --> 00:01:10,301
You'll notice there are actually two xhr

27
00:01:10,301 --> 00:01:12,758
requests. The first request is to the

28
00:01:12,758 --> 00:01:15,063
order statuses endpoint, and the second

29
00:01:15,063 --> 00:01:18,028
request is to the orders endpoint. Once

30
00:01:18,028 --> 00:01:20,735
the data comes back from the orders call,

31
00:01:20,735 --> 00:01:23,498
which can be seen in the onload function

32
00:01:23,498 --> 00:01:26,817
of the xhr request, it looks up the order

33
00:01:26,817 --> 00:01:28,757
status for that particular order in the

34
00:01:28,757 --> 00:01:32,250
list of order statuses that was returned

35
00:01:32,250 --> 00:01:34,479
above. Switching over to my browser, I can

36
00:01:34,479 --> 00:01:37,786
run the code that you just saw. When I

37
00:01:37,786 --> 00:01:40,754
click the Race Condition, the results in

38
00:01:40,754 --> 00:01:43,471
the bordered area below will update. You

39
00:01:43,471 --> 00:01:46,653
can see that the value comes back as

40
00:01:46,653 --> 00:01:48,436
undefined. That could be for a variety of

41
00:01:48,436 --> 00:01:49,902
reasons, including a bug in the code when

42
00:01:49,902 --> 00:01:52,853
we look up our status, but there's not a

43
00:01:52,853 --> 00:01:55,557
bug. Take a look at the console, what do

44
00:01:55,557 --> 00:01:58,316
you see? Do you notice that the /orders

45
00:01:58,316 --> 00:02:01,490
request comes back before the

46
00:02:01,490 --> 00:02:03,792
/orderStatuses request? This is ultimately

47
00:02:03,792 --> 00:02:06,244
what produced the undefined result. Going

48
00:02:06,244 --> 00:02:09,231
back into the code, you can see that we

49
00:02:09,231 --> 00:02:11,745
try to look up the orderStatus description

50
00:02:11,745 --> 00:02:14,401
by comparing the current orderStatusId

51
00:02:14,401 --> 00:02:18,340
against a list of status IDs that we

52
00:02:18,340 --> 00:02:21,762
already fetched. But, if the orderStatus

53
00:02:21,762 --> 00:02:25,077
call returns after the orders call, then

54
00:02:25,077 --> 00:02:27,694
our list is empty, and this is what

55
00:02:27,694 --> 00:02:30,178
produces the undefined response in our

56
00:02:30,178 --> 00:02:32,421
application. Code like this is not unusual

57
00:02:32,421 --> 00:02:34,984
when people first learn JavaScript. Most

58
00:02:34,984 --> 00:02:37,207
people have written code like this, and

59
00:02:37,207 --> 00:02:40,009
they've seen it fail, just like this. We

60
00:02:40,009 --> 00:02:41,477
can fix this code so that the correct

61
00:02:41,477 --> 00:02:44,282
value returns, and displays in our results

62
00:02:44,282 --> 00:02:46,245
area. All we have to do is move a little

63
00:02:46,245 --> 00:02:48,653
bit of code around. We'll see what code we

64
00:02:48,653 --> 00:02:53,000
have to move, and where it has to go, next.

