1
00:00:00,990 --> 00:00:07,080
In the last section we made it clear he looked through our users collection and find exactly one record

2
00:00:07,440 --> 00:00:13,730
where someone had a google id of the profile ID that was just returned by the process.

3
00:00:13,740 --> 00:00:15,430
Now we made a query right here.

4
00:00:15,460 --> 00:00:21,150
Anytime we make a query that reaches out to our Mongo database which means it's an asynchronous operation

5
00:00:21,330 --> 00:00:24,150
and to deal with that we get a promise.

6
00:00:24,150 --> 00:00:29,570
So we changed on then that was called within the existing user if one was found.

7
00:00:29,730 --> 00:00:36,240
So existing user right here is either going to be a mongo mob it's a mongoose model instance I remember

8
00:00:36,260 --> 00:00:44,490
an instance represents exactly one record or existing user will be NULL if the record was not found.

9
00:00:44,520 --> 00:00:50,160
So we were then able to look at the existing user and say if something exists there like if that is

10
00:00:50,220 --> 00:00:52,740
a user model instance then great.

11
00:00:52,740 --> 00:00:54,330
We've already got a record.

12
00:00:54,330 --> 00:00:59,670
Otherwise if the existing user is no well then obviously we need to create a new one and save it to

13
00:00:59,670 --> 00:01:01,280
the database.

14
00:01:01,290 --> 00:01:07,040
So now we've got all this logic put together we need to do one last thing inside of this callback function.

15
00:01:07,110 --> 00:01:11,700
So I've taken the diagram that we're looking at just a second ago and I added that it added in one last

16
00:01:11,700 --> 00:01:19,410
step to be clear the Google strategy that we are making use of gives us this callback explicitly so

17
00:01:19,410 --> 00:01:25,380
that we can do exactly what we are doing right now which is to create a record or save a record for

18
00:01:25,380 --> 00:01:28,830
a database that represents this new user.

19
00:01:28,830 --> 00:01:35,340
So after we have finished with all this user creation or this user fetching stuff to tell passport or

20
00:01:35,340 --> 00:01:41,010
to tell that strategy that we are all done doing our thing we have to inform it that we're finished

21
00:01:41,280 --> 00:01:45,220
by calling the done callback or the done function.

22
00:01:45,330 --> 00:01:50,290
This tells passport that we have now finished making this user we've finished all this kind of junk.

23
00:01:50,460 --> 00:01:53,780
And it should now resume the authentication process.

24
00:01:53,880 --> 00:01:59,640
And so this dumb thing right here we already have included inside the callback.

25
00:01:59,640 --> 00:02:03,660
Look at the argument list to the callback and you'll notice that the fourth argument is called.

26
00:02:03,660 --> 00:02:05,090
Done.

27
00:02:05,190 --> 00:02:10,250
So this is a function when every call done it tells passport hey we're finished here.

28
00:02:10,260 --> 00:02:12,760
We've made the user Here's the user.

29
00:02:12,770 --> 00:02:14,220
This is it we're all finished.

30
00:02:14,220 --> 00:02:16,600
Proceed with the authentication flow.

31
00:02:17,160 --> 00:02:23,970
So let's make sure that after we have found an existing user or saved into the database we tell passport

32
00:02:23,970 --> 00:02:27,810
that we are all complete by calling this done function.

33
00:02:27,870 --> 00:02:33,840
So we'll take care of the first case first and which we found a record inside of our collection and

34
00:02:33,840 --> 00:02:34,370
we will call.

35
00:02:34,370 --> 00:02:36,050
Done.

36
00:02:36,120 --> 00:02:41,040
Now it's not as easy as just calling done like so we have to provide two arguments to it.

37
00:02:41,040 --> 00:02:44,250
The first argument will be an air object.

38
00:02:44,250 --> 00:02:49,530
This object communicates back to a passport that maybe something went wrong or maybe something didn't

39
00:02:49,530 --> 00:02:51,720
quite work the way we expected.

40
00:02:51,720 --> 00:02:57,030
Now if we found a user inside of a user's collection that means everything went fine and totally according

41
00:02:57,030 --> 00:02:57,810
to plan.

42
00:02:57,990 --> 00:03:02,970
So we will pass in a first argument of all which indicates hey there's no air here.

43
00:03:02,970 --> 00:03:04,560
Everything went completely fine.

44
00:03:04,560 --> 00:03:06,630
Right we are totally happy.

45
00:03:06,630 --> 00:03:12,450
Then the second argument will be the user record which is existing user.

46
00:03:13,290 --> 00:03:18,150
So this tells Monck this tells passport hey we're all finished here.

47
00:03:18,150 --> 00:03:21,290
Here is the user that we just found or the user that we just created.

48
00:03:21,300 --> 00:03:24,670
Everything is done we are finished now.

49
00:03:24,870 --> 00:03:29,640
This is going to work out just fine for the first case but for the second case we have to do something

50
00:03:29,700 --> 00:03:31,920
a little bit more complex.

51
00:03:31,920 --> 00:03:38,310
Remember any time we save a record to our Mongo database it is an asynchronous operation.

52
00:03:38,400 --> 00:03:44,850
We do not want to call it done right here until we know for a fact that the user has been successfully

53
00:03:44,850 --> 00:03:46,590
saved to the database.

54
00:03:46,590 --> 00:03:52,860
So in order to get a notification or get some something to tell us that yes the user has been successfully

55
00:03:52,860 --> 00:04:00,390
saved right here we have to chain on a dot then statement then statement will be called with the new

56
00:04:00,390 --> 00:04:02,380
user who has just saved.

57
00:04:02,730 --> 00:04:05,370
So we'll take the user was just saved.

58
00:04:05,610 --> 00:04:11,280
That's provided as an argument to the function that we passed to then and then just like we did right

59
00:04:11,280 --> 00:04:15,140
here we will take that new user who has just saved the database.

60
00:04:15,360 --> 00:04:18,430
We would call done with the first argument of Noal.

61
00:04:18,750 --> 00:04:24,930
And then as a second argument we will pass and the user who has just saved.

62
00:04:25,000 --> 00:04:30,020
OK so just to kind of clarify something that I have found is sometimes confusing for people.

63
00:04:30,200 --> 00:04:37,970
When we called new user right here remember that creates a Mungo's mongoose model instance a model instance

64
00:04:37,970 --> 00:04:41,270
represents a single record inside of our collection.

65
00:04:41,270 --> 00:04:48,260
So this creates a new model right here a new model instance we then save that instance and in the callback

66
00:04:48,860 --> 00:04:51,020
we get another model instance.

67
00:04:51,020 --> 00:04:54,800
So at this point we are really working with like two separate model instances.

68
00:04:54,800 --> 00:04:56,970
We've got the one that we just created right here.

69
00:04:57,110 --> 00:05:00,060
And then we have a second instance right here.

70
00:05:00,110 --> 00:05:06,860
Now they both represent the exact same underlying model or the exact same record inside of our collection

71
00:05:07,490 --> 00:05:12,710
but by convention we always make use of the one that's provided to us inside of the promised callback

72
00:05:13,130 --> 00:05:18,620
because this one might have some additional changes to that was made to it while the user was being

73
00:05:18,620 --> 00:05:19,440
saved.

74
00:05:19,730 --> 00:05:24,890
So we kind of consider this initial user that we created right here to be like not quite as fresh not

75
00:05:24,890 --> 00:05:32,510
quite as clean not as quite as well-maintained as the user that we just got back from the database so

76
00:05:32,510 --> 00:05:33,280
that's pretty much it.

77
00:05:33,290 --> 00:05:38,090
We're now ready to test this out inside the browser before we test it so I want to say really quickly.

78
00:05:38,150 --> 00:05:42,890
This has been our first taste of mongoose and as we've been working with it we've also been kind of

79
00:05:42,890 --> 00:05:48,590
like simultaneously juggling this passport stuff and so at this point a lot of the scene probably seems

80
00:05:48,590 --> 00:05:49,680
kind of confusing.

81
00:05:49,820 --> 00:05:56,540
And then on top of all of it we have also introduce some promises after we get everything on our authentication

82
00:05:56,540 --> 00:05:57,380
flow working.

83
00:05:57,380 --> 00:06:02,630
We're going to come back to this callback and refactor it to make it look a lot more legible than it

84
00:06:02,630 --> 00:06:03,540
does right now.

85
00:06:03,740 --> 00:06:06,760
So if this still looks confusing Don't sweat it in a little bit.

86
00:06:06,760 --> 00:06:07,520
We'll come back.

87
00:06:07,520 --> 00:06:10,210
We will refactor it to make it look much nicer.

88
00:06:10,310 --> 00:06:16,770
And at that point we will have a second chance to understand exactly what is going on inside this function.

89
00:06:16,820 --> 00:06:22,880
Ok so last thing we will test this out I'm going to make sure that my server is running and I do not

90
00:06:22,880 --> 00:06:27,150
have any errors and yet looks like everything is OK.

91
00:06:27,910 --> 00:06:29,970
I'm going to change back over to my browser.

92
00:06:30,650 --> 00:06:35,450
I will access localhost 5000 slash off slash Google.

93
00:06:35,750 --> 00:06:41,510
And before I go there just really quick I want to point out my users collection I've only got a single

94
00:06:41,510 --> 00:06:42,620
record in there right now.

95
00:06:42,650 --> 00:06:46,380
So I deleted the duplicate record that we already had.

96
00:06:46,760 --> 00:06:52,520
So just one record at this point you can delete records in here by the way by clicking on a little trash

97
00:06:52,550 --> 00:06:54,300
icon right here.

98
00:06:55,350 --> 00:06:55,630
OK.

99
00:06:55,640 --> 00:06:57,830
So we'll go here.

100
00:06:57,830 --> 00:07:01,400
When I do so I can go refresh the collection.

101
00:07:01,400 --> 00:07:03,530
I still only have one record in here.

102
00:07:03,530 --> 00:07:05,540
Yup looks good.

103
00:07:05,540 --> 00:07:08,440
Now it looks like nothing is still happening inside the browser.

104
00:07:08,450 --> 00:07:13,640
So perhaps we saw a little bit of work to do on the passport side but we can at least rest easy knowing

105
00:07:13,640 --> 00:07:17,960
that we have correctly progressed out of this callback function right here.

106
00:07:18,230 --> 00:07:24,690
So clearly mug passport still expects us to do something to kind of Usher along the authentication process.

107
00:07:24,710 --> 00:07:26,100
So let's take a quick break.

108
00:07:26,120 --> 00:07:30,860
We'll come back in the next section and figure out exactly how we're going to kind of push passport

109
00:07:30,860 --> 00:07:33,900
along to the next step in the authentication flow.

110
00:07:34,160 --> 00:07:36,530
So I will see you in just a second.