1
00:00:01,497 --> 00:00:03,563
As we've seen, nesting callbacks can lead

2
00:00:03,563 --> 00:00:06,345
to messy code. How can we get the benefits

3
00:00:06,345 --> 00:00:09,466
of nesting without the messiness of

4
00:00:09,466 --> 00:00:11,473
nesting? The answer, as you might've

5
00:00:11,473 --> 00:00:14,103
guessed, is promises, but what is a

6
00:00:14,103 --> 00:00:16,396
promise? According to Mozilla, a promise

7
00:00:16,396 --> 00:00:18,933
is an object that represents the eventual

8
00:00:18,933 --> 00:00:21,948
completion (or failure) of an asynchronous

9
00:00:21,948 --> 00:00:26,462
operation, and its resulting value. Right

10
00:00:26,462 --> 00:00:28,132
off the bat, we see that it's an object

11
00:00:28,132 --> 00:00:30,321
that helps with an asynchronous operation,

12
00:00:30,321 --> 00:00:32,667
which is what we've been dealing with. It

13
00:00:32,667 --> 00:00:34,572
also tells us that it represents the

14
00:00:34,572 --> 00:00:37,429
eventual completion. That is, when a

15
00:00:37,429 --> 00:00:39,849
promise is called, it may or may not have

16
00:00:39,849 --> 00:00:41,955
a value. The value could come instantly,

17
00:00:41,955 --> 00:00:44,221
or it could come at some time in the

18
00:00:44,221 --> 00:00:46,042
future, like our orderStatuses call that

19
00:00:46,042 --> 00:00:48,275
takes one and a half seconds. Another way

20
00:00:48,275 --> 00:00:50,384
to think of it is that promises allow

21
00:00:50,384 --> 00:00:53,132
developers to write asynchronous code in a

22
00:00:53,132 --> 00:00:54,883
more clear and less error-prone manner,

23
00:00:54,883 --> 00:00:57,462
and that was a big part of my motivation

24
00:00:57,462 --> 00:01:00,102
when I first learned promises. Even though

25
00:01:00,102 --> 00:01:02,453
the concepts were not intuitive at first,

26
00:01:02,453 --> 00:01:04,860
I persisted, because I wanted my

27
00:01:04,860 --> 00:01:08,987
JavaScript code to be more readable. A

28
00:01:08,987 --> 00:01:11,524
promise can have three states. First,

29
00:01:11,524 --> 00:01:14,330
pending. This is the initial state, when

30
00:01:14,330 --> 00:01:17,211
you first create a promise, it's in the

31
00:01:17,211 --> 00:01:19,523
pending state. Since we're talking a lot

32
00:01:19,523 --> 00:01:22,135
about API calls, while the call is

33
00:01:22,135 --> 00:01:24,853
happening, the promise is pending. If you

34
00:01:24,853 --> 00:01:26,321
remember the orderStatuses call that took

35
00:01:26,321 --> 00:01:28,905
one and a half seconds to respond, a

36
00:01:28,905 --> 00:01:30,919
promise would've been in the pending state

37
00:01:30,919 --> 00:01:34,747
for the entire one and a half seconds.

38
00:01:34,747 --> 00:01:37,284
Second, fulfill. A promise moves from the

39
00:01:37,284 --> 00:01:39,866
pending to the fulfilled state when the

40
00:01:39,866 --> 00:01:42,255
asynchronous call has completed

41
00:01:42,255 --> 00:01:44,228
successfully. When a promise is fulfilled,

42
00:01:44,228 --> 00:01:47,120
it will return a single value. For

43
00:01:47,120 --> 00:01:51,312
example, a specific order from an API. The

44
00:01:51,312 --> 00:01:53,426
third and final state is rejected. A

45
00:01:53,426 --> 00:01:55,351
promise moves from the pending to the

46
00:01:55,351 --> 00:01:57,734
rejected state when the asynchronous call

47
00:01:57,734 --> 00:02:00,990
has failed. When a promise is rejected, it

48
00:02:00,990 --> 00:02:03,211
returns a reason why it was rejected;

49
00:02:03,211 --> 00:02:05,424
similar to the catch function in a try-

50
00:02:05,424 --> 00:02:07,877
catch block. There are a couple other

51
00:02:07,877 --> 00:02:09,896
terms that you might hear with promises.

52
00:02:09,896 --> 00:02:11,541
You might hear someone say that a promise

53
00:02:11,541 --> 00:02:15,910
is settled, or resolved. Both of these are

54
00:02:15,910 --> 00:02:18,110
referring to the same state. Whenever

55
00:02:18,110 --> 00:02:20,379
someone says a promise is settled or

56
00:02:20,379 --> 00:02:22,620
resolved, they mean that that promise is

57
00:02:22,620 --> 00:02:26,625
now in either the fulfilled or rejected

58
00:02:26,625 --> 00:02:29,384
state. That is, it means that a promise is

59
00:02:29,384 --> 00:02:32,445
no longer pending. One quick note while

60
00:02:32,445 --> 00:02:34,393
we're talking about the definition of

61
00:02:34,393 --> 00:02:36,334
promises; if you're coming from another

62
00:02:36,334 --> 00:02:38,517
language to JavaScript, you might already

63
00:02:38,517 --> 00:02:40,843
be familiar with a concept called

64
00:02:40,843 --> 00:02:43,003
promises. In some languages, these

65
00:02:43,003 --> 00:02:46,119
promises are a term used for lazy

66
00:02:46,119 --> 00:02:49,547
evaluation of code. In JavaScript, that is

67
00:02:49,547 --> 00:02:53,051
not the case. JavaScript promises are

68
00:02:53,051 --> 00:02:55,068
eagerly evaluated. Throughout the rest of

69
00:02:55,068 --> 00:02:56,549
the course, we'll see how we can get the

70
00:02:56,549 --> 00:02:58,393
values out of a promise, but it's

71
00:02:58,393 --> 00:03:00,611
important to note that promises do not

72
00:03:00,611 --> 00:03:03,946
wait for us to request the value before

73
00:03:03,946 --> 00:03:06,771
they execute. With that brief theory of

74
00:03:06,771 --> 00:03:08,159
promises, you're probably ready to start

75
00:03:08,159 --> 00:03:10,151
seeing them in practice. There's one quick

76
00:03:10,151 --> 00:03:15,000
step we need to do first, and I'll walk you through that, next.

