1
00:00:01,030 --> 00:00:05,720
We were just able to successfully save a user to our users collection for the very first time.

2
00:00:05,740 --> 00:00:10,060
So now we need to kind of go back a little bit and make sure that we do some kind of test to make sure

3
00:00:10,060 --> 00:00:12,790
that no one's ever signed up but they give an email before.

4
00:00:13,090 --> 00:00:17,590
Before we add in any code for that let's just tried to create a another user account with the same email

5
00:00:17,620 --> 00:00:20,370
as the first one and see what happens right now.

6
00:00:20,380 --> 00:00:25,600
So back inside of postmen I'm going to make sure I've got the same email and password that I had inside

7
00:00:25,600 --> 00:00:30,610
of here from my first user that I created and I'll send the request when I send the request.

8
00:00:30,610 --> 00:00:34,020
It looks like it's just kind of hanging here and not resolving at all.

9
00:00:34,150 --> 00:00:38,800
So let's try flipping over to our terminal and see what happens back over inside my terminal.

10
00:00:38,830 --> 00:00:41,340
I'll immediately see a giant error message here.

11
00:00:41,340 --> 00:00:46,450
The error message says that we've got a duplicate key in collection users.

12
00:00:46,450 --> 00:00:51,640
So remember when we put together our user model back inside of our user J.S. file right here when we

13
00:00:51,640 --> 00:00:57,190
defined that email a property right here we added on the flag of unique true by adding on unique true

14
00:00:57,280 --> 00:01:03,910
mongoose is going to modify our Mongo DB collection of users and it's going to tell Mongo D.B. that

15
00:01:03,970 --> 00:01:09,190
every user must have a unique email so we don't have to do any additional steps to make sure that a

16
00:01:09,190 --> 00:01:15,550
given email is not in use mongoose is going to already do that for us automatically.

17
00:01:15,550 --> 00:01:19,450
And there's one other scenario that we need to be aware of around this kind of error handling stuff

18
00:01:19,450 --> 00:01:20,500
as well.

19
00:01:20,500 --> 00:01:25,390
The other scenario I want to point out very quickly is that if we cancel it's running requests and if

20
00:01:25,390 --> 00:01:30,220
we remove the email and password altogether from the request we are making and then send that request

21
00:01:30,220 --> 00:01:30,860
as well.

22
00:01:30,880 --> 00:01:35,800
We once again are going to have a hanging request so we can flip back over to our terminal once again

23
00:01:36,280 --> 00:01:40,180
see another giant error message here and kind of tucked away inside this error message.

24
00:01:40,180 --> 00:01:42,410
It says user validation failed.

25
00:01:42,460 --> 00:01:46,360
We have to have a email and we have to have a password as well.

26
00:01:46,450 --> 00:01:51,880
And once again we're getting those error messages because we put in a required flag of true on our user

27
00:01:51,880 --> 00:01:52,900
schema.

28
00:01:52,900 --> 00:01:57,310
So it turns out that by defining this user schema and putting into unique and required properties inside

29
00:01:57,310 --> 00:02:01,120
of here mongoose is already doing a lot of validation for us.

30
00:02:01,150 --> 00:02:06,220
So all we have to do is somehow catch this error that mongoose is throwing when we try to save our user

31
00:02:06,550 --> 00:02:12,750
and relay that error message back to whoever making is a request a request to our API so to do so we'll

32
00:02:12,750 --> 00:02:17,430
go back over to author routes when we attempt to save our user to the database.

33
00:02:17,460 --> 00:02:19,260
That is when our validation is occurring.

34
00:02:19,330 --> 00:02:24,090
So that's when mongoose is going to check to make sure that we provided an email and a password and

35
00:02:24,090 --> 00:02:29,510
when Mongoose reaches out to mongo DV and attempts to save the user that's when the check to see if

36
00:02:29,520 --> 00:02:32,500
you email is unique is going to occur as well.

37
00:02:32,520 --> 00:02:37,230
So if you want to catch any error that is thrown during that process we can wrap this entire block right

38
00:02:37,230 --> 00:02:44,840
here with a tri catch statement so I'll put those three lines of code inside of a try statement close

39
00:02:44,980 --> 00:02:50,700
it off with a catch and inside of this catch statement right here we can catch any error that's thrown

40
00:02:50,760 --> 00:02:57,810
during that safe process yet either a unique email validation error or the lack of an email or password.

41
00:02:57,810 --> 00:03:02,430
So then inside of here we can send that error message back to the user and tell them exactly what went

42
00:03:02,430 --> 00:03:03,660
wrong when they tried to sign up.

43
00:03:04,530 --> 00:03:08,020
So inside of here we could do a red dot status.

44
00:03:08,040 --> 00:03:14,430
So we're going to set the age TTP status code on the response I'll put in a four twenty two which indicates

45
00:03:14,430 --> 00:03:21,190
that the user sent us some invalid data to create a new user then I'll put a send inside of here and

46
00:03:21,190 --> 00:03:23,400
send back an actual distinct error message.

47
00:03:23,590 --> 00:03:28,240
In this case we don't really know what went wrong either the user provided a duplicate email or they

48
00:03:28,240 --> 00:03:30,100
didn't provide the email or password.

49
00:03:30,100 --> 00:03:35,800
So for right now we'll just send back ja dot message and that's going to be essentially a message that

50
00:03:35,800 --> 00:03:39,220
is produced by Mongoose for us automatically.

51
00:03:39,220 --> 00:03:44,140
I'm also going to put a return inside there as well to make sure that if I ever add in any code after

52
00:03:44,140 --> 00:03:48,730
this try catch statement I won't attempt to execute that code because something already went wrong up

53
00:03:48,730 --> 00:03:52,110
here so I don't want to try doing anything else OK.

54
00:03:52,160 --> 00:03:58,340
Let's save this and try submitting some invalid requests again so I'll save that file.

55
00:03:58,360 --> 00:03:59,720
I'll go back over the post man.

56
00:03:59,860 --> 00:04:05,650
I'm first going to try making a request without anybody inside the request or I should be more be more

57
00:04:05,650 --> 00:04:08,240
exact without an email or password.

58
00:04:08,590 --> 00:04:14,260
Now when I send the request I immediately get a response and that response says user validation failed

59
00:04:14,440 --> 00:04:17,580
because you have to have an email and a password.

60
00:04:17,590 --> 00:04:25,420
So now if I enter in an email and a password and I'm going to put in the same email that I put in previously.

61
00:04:25,440 --> 00:04:30,100
So this is a email that's already in use.

62
00:04:30,210 --> 00:04:33,810
I'll send that an LLC duplicate Eric key in collection.

63
00:04:33,810 --> 00:04:36,080
We've already made use this email before.

64
00:04:36,210 --> 00:04:40,260
Now I want to point out that the error messages that we're sending back to ever makes this request are

65
00:04:40,260 --> 00:04:41,760
not very user friendly.

66
00:04:41,790 --> 00:04:45,660
In other words if we just put this error message directly in front of a user they would probably have

67
00:04:45,720 --> 00:04:48,060
no idea what we're talking about.

68
00:04:48,060 --> 00:04:52,230
Nonetheless we're just going to leave it like this for right now because well once again we're kind

69
00:04:52,230 --> 00:04:54,320
of focused on the react native side of things.

70
00:04:54,330 --> 00:04:58,070
I just want to point out that perhaps these error messages are not that great for use right now.

71
00:04:59,190 --> 00:04:59,430
OK.

72
00:04:59,430 --> 00:05:01,570
So we've now got some better air handling inside of here.

73
00:05:01,680 --> 00:05:07,020
And we also kind of automatically implemented that check to make sure that the email of test at test

74
00:05:07,020 --> 00:05:10,410
dot com or whatever it is is not in use.

75
00:05:10,440 --> 00:05:15,990
So now if a user gets past that check and if they also provide a email and password now it's time for

76
00:05:15,990 --> 00:05:20,430
us to attempt to create a Jason web token and send that back to our user.

77
00:05:20,430 --> 00:05:25,150
Remember they're gonna use this token as a means to authenticate themselves on future requests.

78
00:05:25,680 --> 00:05:29,610
So now that we've got this error handling in let's take another pause when we come back the next section

79
00:05:29,850 --> 00:05:33,580
we're gonna have a quick discussion and understand what a Jason web token is.

80
00:05:33,740 --> 00:05:37,920
And then whenever user signs in from our sign up Handler right here we're going to make sure that we

81
00:05:37,920 --> 00:05:40,770
create this Jason web token and send it back.

82
00:05:40,770 --> 00:05:42,810
So we'll stay clear that in just a moment.