1
00:00:03,650 --> 00:00:08,385
Nous avions déjà développé un serveur d'API REST à part entière

2
00:00:08,385 --> 00:00:12,485
en utilisant Express et MongoDB dans le cadre de ce cours.

3
00:00:12,485 --> 00:00:16,965
Pour que ce serveur puisse communiquer de manière significative avec notre client,

4
00:00:16,965 --> 00:00:19,590
nous y apporterons quelques ajustements mineurs

5
00:00:19,590 --> 00:00:22,440
afin qu'il renvoie le bon type de données afin que

6
00:00:22,440 --> 00:00:24,780
notre implémentation client puisse fonctionner plus

7
00:00:24,780 --> 00:00:28,935
efficacement avec les données renvoyées par notre site serveur.

8
00:00:28,935 --> 00:00:30,410
Donc, pour ce faire,

9
00:00:30,410 --> 00:00:36,580
nous allons travailler sur quelques ajustements à notre site serveur dans cet exercice.

10
00:00:36,580 --> 00:00:39,215
Avant de commencer cet exercice,

11
00:00:39,215 --> 00:00:42,410
je suppose que vous n'avez pas fait

12
00:00:42,410 --> 00:00:46,430
la leçon précédente sur l'intégration du client angulaire et

13
00:00:46,430 --> 00:00:55,395
du serveur parce que vous faites cette leçon en passant par la spécialisation React.

14
00:00:55,395 --> 00:01:01,190
Donc, les modifications que je vais apporter au serveur supposent que

15
00:01:01,190 --> 00:01:07,430
la version du serveur que vous modifiez est antérieure à la leçon précédente.

16
00:01:07,430 --> 00:01:11,540
Dans le cas où vous avez fait cette leçon sur

17
00:01:11,540 --> 00:01:16,505
le client angulaire, certaines des modifications que vous avez apportées à votre serveur seront répétées

18
00:01:16,505 --> 00:01:22,495
dans cet exercice afin que vous puissiez ignorer cette partie des modifications.

19
00:01:22,495 --> 00:01:26,055
Accédez à notre serveur dans l'éditeur.

20
00:01:26,055 --> 00:01:29,125
Avant de commencer à travailler sur le serveur,

21
00:01:29,125 --> 00:01:33,530
je vous suggère de télécharger toutes les images que j'ai

22
00:01:33,530 --> 00:01:38,380
fournies sous forme de fichier zip dans les ressources d'exercice appelées images.zip.

23
00:01:38,380 --> 00:01:43,160
Décompressez le fichier, puis obtenez toutes les images à partir de là, puis copiez ces images

24
00:01:43,160 --> 00:01:48,290
dans le dossier des images publiques de notre serveur.

25
00:01:48,290 --> 00:01:55,010
Donc, vous voyez qu'ici j'ai copié toutes les images dans mon dossier d'images publiques ici

26
00:01:55,010 --> 00:01:58,160
déjà parce que notre serveur est celui qui va

27
00:01:58,160 --> 00:02:02,275
servir toutes ces images pour notre application client.

28
00:02:02,275 --> 00:02:07,835
Ensuite, nous allons au CORS et ajustons la liste blanche ici.

29
00:02:07,835 --> 00:02:11,565
Donc, pour notre application client React,

30
00:02:11,565 --> 00:02:15,275
si nous avons démarré avec la commande yarn start,

31
00:02:15,275 --> 00:02:18,470
elle s'exécute à votre nom d'ordinateur:3001.

32
00:02:18,470 --> 00:02:22,040
Donc, toute demande venant de notre emplacement vers

33
00:02:22,040 --> 00:02:25,760
le serveur portera cela comme origine là-bas.

34
00:02:25,760 --> 00:02:30,380
C' est pourquoi je vais ajouter cela dans ma liste blanche afin que

35
00:02:30,380 --> 00:02:35,390
tous les problèmes CORS soient résolus automatiquement.

36
00:02:35,390 --> 00:02:40,985
Donc, en entrant dans le fichier cors.js dans ma liste blanche ici,

37
00:02:40,985 --> 00:02:49,460
permettez-moi d'ajouter le

38
00:02:49,460 --> 00:02:55,640
nom de l'ordinateur http://my : 3001 et c'est

39
00:02:55,640 --> 00:02:58,610
l'origine à partir de laquelle mon client

40
00:02:58,610 --> 00:03:02,075
sera à l'origine des requêtes qui viennent à ce serveur.

41
00:03:02,075 --> 00:03:07,075
Donc, de cette façon, mon CORS ne causerait pas de problèmes pour mon client.

42
00:03:07,075 --> 00:03:11,690
Ensuite, nous devons mettre à jour quelques-unes des routes pour

43
00:03:11,690 --> 00:03:17,690
gérer les paramètres de requête et aussi quelques autres ajustements mineurs.

44
00:03:17,690 --> 00:03:21,280
Laissez-moi commencer par le fichier promoRouter.js.

45
00:03:21,280 --> 00:03:25,010
C' est simple de se mettre à jour.

46
00:03:25,010 --> 00:03:27,570
Donc, en allant dans le fichier promoRouter.js,

47
00:03:27,570 --> 00:03:32,360
dans le fichier Promorouter pour la requête get que nous obtenons

48
00:03:32,360 --> 00:03:37,610
ici au lieu de faire des promotions trouver avec un objet JavaScript vide,

49
00:03:37,610 --> 00:03:47,320
ici je fournirais le req.query comme paramètre pour les promotions trouver ici,

50
00:03:47,320 --> 00:03:49,680
même chose avec le routeur leader aussi.

51
00:03:49,680 --> 00:03:52,745
Donc, laissez-moi aller au fichier leaderRouter.js.

52
00:03:52,745 --> 00:03:54,815
Dans le routeur de leader aussi,

53
00:03:54,815 --> 00:04:00,545
ici où vous trouvez leaders.Find avec l'objet JavaScript vide

54
00:04:00,545 --> 00:04:06,685
remplacer cela par le req.query afin que les paramètres de requête soient transmis.

55
00:04:06,685 --> 00:04:14,260
Donc, c'est là que nous allons passer dans le featured:true comme paramètre de requête ici.

56
00:04:14,260 --> 00:04:16,945
Maintenant, après avoir ajusté ces deux,

57
00:04:16,945 --> 00:04:19,340
travaillons maintenant sur le routeur à vaisselle.

58
00:04:19,340 --> 00:04:22,115
Donc, allez dans le fichier dishRouter.js,

59
00:04:22,115 --> 00:04:26,310
même dans le routeur plat aussi la même mise à jour ici.

60
00:04:26,310 --> 00:04:31,200
Donc, allez dans ce plats.Trouver dans la méthode get ici,

61
00:04:31,200 --> 00:04:33,945
changez cela en req.query.

62
00:04:33,945 --> 00:04:38,070
Donc, avec cela, ma mise à jour de routeur plat a été terminée.

63
00:04:38,070 --> 00:04:42,085
Donc, nous avons maintenant mis à jour le routeur promo, le leader,

64
00:04:42,085 --> 00:04:43,850
et le routeur plat,

65
00:04:43,850 --> 00:04:48,050
puis nous allons passer à mettre à jour le routeur préféré.

66
00:04:48,050 --> 00:04:54,380
Maintenant, vous auriez implémenté le routeur favori dans le cadre de votre quatrième affectation.

67
00:04:54,380 --> 00:04:56,530
Maintenant, dans le routeur préféré,

68
00:04:56,530 --> 00:04:58,910
vous verrez que pour le routeur préféré,

69
00:04:58,910 --> 00:05:01,010
je ne vous montre pas la partie restante parce que

70
00:05:01,010 --> 00:05:03,435
vous auriez dû faire dans le cadre de votre affectation. Tout d'

71
00:05:03,435 --> 00:05:11,520
abord, permettez-moi d'attirer votre attention sur la méthode get pour le favoriTerouter.route:Dishid.

72
00:05:11,520 --> 00:05:17,405
Maintenant, je vais utiliser cette méthode get pour vérifier simplement que

73
00:05:17,405 --> 00:05:25,460
le plat spécifique avec le plat Id est déjà un favori pour l'utilisateur.

74
00:05:25,460 --> 00:05:29,130
Donc, au lieu de simplement dire getoperation.supported,

75
00:05:29,130 --> 00:05:36,165
je vais juste tirer parti de la présence de cette opération get et ensuite nous dirons,

76
00:05:36,165 --> 00:05:47,500
favorites.findone et nous dirons utilisateur : req.user. _id.

77
00:05:49,220 --> 00:05:59,340
Donc, nous allons trouver les favoris pour cet utilisateur particulier, puis nous dirons ensuite les

78
00:06:03,070 --> 00:06:25,530
favoris et attraper l'erreur suivante.

79
00:06:25,530 --> 00:06:35,265
Ensuite, de même ici, nous allons ajouter dans l'erreur ici, prochaine erreur ici.

80
00:06:35,265 --> 00:06:37,380
Donc, à l'intérieur de cela alors,

81
00:06:37,380 --> 00:06:39,495
quand nous obtenons les favoris,

82
00:06:39,495 --> 00:06:45,360
alors nous vérifierons si ce n'est pas les favoris.

83
00:06:45,360 --> 00:06:47,690
Donc, s'il n'y a pas de favoris pour

84
00:06:47,690 --> 00:06:53,900
cet utilisateur, alors évidemment le plat que nous vérifions n'existe pas,

85
00:06:53,900 --> 00:07:07,520
donc nous allons retourner res.StatusCode 200,

86
00:07:07,520 --> 00:07:14,370
setHeader, Content-Type,

87
00:07:17,230 --> 00:07:36,735
application/json et ensuite nous reviendrons dire existe false.

88
00:07:36,735 --> 00:07:44,215
Ce que nous spécifions ici est que s'ils obtiennent est fait à ce point final avec un ID plat,

89
00:07:44,215 --> 00:07:52,835
cela existe drapeau ici sera réglé sur true si ce plat fait partie de mes favoris.

90
00:07:52,835 --> 00:07:55,290
Si ce plat ne fait pas partie de mes favoris,

91
00:07:55,290 --> 00:07:58,100
je vais définir il existe drapeau à false.

92
00:07:58,100 --> 00:08:01,190
Donc, ici, vous voyez que puisque je n'ai pas de favoris,

93
00:08:01,190 --> 00:08:04,770
il existe donc devrait être automatiquement faux à ce stade.

94
00:08:04,770 --> 00:08:13,020
Donc, nous allons dire existe false et ensuite nous allons retourner les favoris ici.

95
00:08:13,180 --> 00:08:19,090
Eh bien, évidemment, dans ce cas, les favoris seraient nuls à ce stade.

96
00:08:19,090 --> 00:08:26,440
Sinon, ce qui signifie que les favoris n'est pas nul,

97
00:08:26,440 --> 00:08:32,750
donc nous dirons si favorites.Dish.IndexOf.

98
00:08:36,840 --> 00:08:45,995
Donc, nous allons chercher Req.params.Dishid.

99
00:08:45,995 --> 00:08:51,220
Donc, nous allons chercher ce tableau de plats favoris pour

100
00:08:51,220 --> 00:08:56,605
voir si ce plat existe et s'il n'existe pas,

101
00:08:56,605 --> 00:09:00,525
évidemment cela retournera un index négatif ici.

102
00:09:00,525 --> 00:09:02,340
Dans ce cas aussi,

103
00:09:02,340 --> 00:09:05,440
je reviendrai exactement le même que ici.

104
00:09:05,440 --> 00:09:08,630
Donc, si elle renvoie un index négatif, cela signifie que

105
00:09:08,630 --> 00:09:12,260
même si cet utilisateur particulier a un ensemble de favoris,

106
00:09:12,260 --> 00:09:16,190
ce plat spécifique n'existe pas dans

107
00:09:16,190 --> 00:09:22,340
la liste de ses favoris donc c'est pourquoi il retournera existe false ici.

108
00:09:22,340 --> 00:09:30,255
Maintenant, sinon cela signifie que le plat existe dans la liste des favoris.

109
00:09:30,255 --> 00:09:31,859
Donc, dans ce cas,

110
00:09:31,859 --> 00:09:36,670
je vais retourner le code d'état 200 existe est vrai.

111
00:09:36,670 --> 00:09:43,825
Ainsi, lorsque l'utilisateur effectue une opération get sur ce point de terminaison avec

112
00:09:43,825 --> 00:09:52,015
le /favorites/dishid où l'ID plat est fourni comme paramètre ici, en

113
00:09:52,015 --> 00:09:55,630
tant que paramètre de requête ici,

114
00:09:55,630 --> 00:10:00,650
nous allons vérifier si ce plat existe dans les favoris.

115
00:10:00,650 --> 00:10:05,775
Si aucun des favoris n'existe pour cet utilisateur, nous retournerons un false existe.

116
00:10:05,775 --> 00:10:08,120
De même, si les favoris existent mais

117
00:10:08,120 --> 00:10:12,320
que ce plat particulier n'existe pas dans les favoris, alors nous retournerons false,

118
00:10:12,320 --> 00:10:13,910
sinon nous retournerons true.

119
00:10:13,910 --> 00:10:20,260
Donc, ce drapeau existe peut être utilisé par mon client pour vérifier si ce plat fait

120
00:10:20,260 --> 00:10:27,755
partie de la liste des plats préférés pour cet utilisateur ou non.

121
00:10:27,755 --> 00:10:30,139
Aussi pendant que nous sommes dans les favoris,

122
00:10:30,139 --> 00:10:33,410
chaque fois que nous faisons des changements aux favoris,

123
00:10:33,410 --> 00:10:37,870
nous voulons être en mesure de remplir les informations de l'utilisateur et de

124
00:10:37,870 --> 00:10:39,535
la vaisselle, les favoris, avant de revenir.

125
00:10:39,535 --> 00:10:43,240
Par exemple, dans le post que nous faisons,

126
00:10:43,240 --> 00:10:48,470
lorsque nous enregistrons les favoris puis à ce stade,

127
00:10:48,470 --> 00:10:55,470
nous aimerions d'abord faire des favoris.

128
00:10:55,620 --> 00:11:06,380
FindById, donc parce que nous venons de faire les changements, nous dirons favorite_id

129
00:11:07,740 --> 00:11:15,325
et nous allons remplir à la fois l'utilisateur et aussi

130
00:11:15,325 --> 00:11:25,490
remplir les plats dans les favoris.

131
00:11:25,740 --> 00:11:32,420
Ensuite, lorsque les favoris sont retournés,

132
00:11:32,610 --> 00:11:36,940
nous retournerons ces favoris à la place.

133
00:11:36,940 --> 00:11:40,440
Alors, laissez-moi faire ce changement ici.

134
00:11:40,440 --> 00:11:46,910
Donc, nous allons découper cela d'ici et puis à l'intérieur de l'alors,

135
00:11:46,910 --> 00:11:49,645
nous allons retourner les favoris.

136
00:11:49,645 --> 00:11:53,510
Après avoir enregistré les favoris,

137
00:11:53,510 --> 00:11:54,980
nous allons chercher,

138
00:11:54,980 --> 00:11:58,285
pour le FavoriteById, puis retourner

139
00:11:58,285 --> 00:12:03,940
ce favori ici afin que nous dirons alors retour favori et code d'état.

140
00:12:03,940 --> 00:12:05,355
Ce changement que nous devrions faire.

141
00:12:05,355 --> 00:12:08,180
Si vous l'avez déjà implémenté dans vos favoris,

142
00:12:08,180 --> 00:12:09,760
vous n'avez pas besoin d'apporter cette modification.

143
00:12:09,760 --> 00:12:13,310
Mais ce que nous faisons, c'est chaque fois que nous apportons des modifications aux favoris,

144
00:12:13,310 --> 00:12:17,380
nous remplirons à la fois les informations de l'utilisateur et de la vaisselle, puis retournerons cette valeur

145
00:12:17,380 --> 00:12:22,360
car notre client React s'attend à ce que cela soit là.

146
00:12:22,360 --> 00:12:24,685
Maintenant, le même type de changement,

147
00:12:24,685 --> 00:12:28,350
nous devrons faire la variable b, enregistrer les changements.

148
00:12:28,350 --> 00:12:33,125
Donc, dans le post ici,

149
00:12:33,125 --> 00:12:36,090
nous allons faire un changement à cela,

150
00:12:36,090 --> 00:12:42,705
donc nous allons dire favorites.enregistrer et ensuite nous ferons favorites.FindById et faire ce changement.

151
00:12:42,705 --> 00:12:45,210
De même, sous l'ID plat,

152
00:12:45,210 --> 00:12:47,095
également dans le poste,

153
00:12:47,095 --> 00:12:51,070
vous serez de la même manière, chaque fois que vous apportez des modifications aux favoris, d'

154
00:12:51,070 --> 00:12:57,715
abord le chercher et ensuite remplir à la fois l'utilisateur et la vaisselle, puis le retourner,

155
00:12:57,715 --> 00:12:59,910
puis de la même manière dans la partie autre.

156
00:12:59,910 --> 00:13:06,290
Donc, vous devez avoir implémenté ceci dans votre quatrième affectation.

157
00:13:06,290 --> 00:13:09,010
Donc, apportez cette modification supplémentaire où vous allez remplir

158
00:13:09,010 --> 00:13:12,350
l'utilisateur et les plats avant de renvoyer la valeur.

159
00:13:12,350 --> 00:13:14,685
Aussi avec la suppression,

160
00:13:14,685 --> 00:13:17,385
nous allons faire les mêmes changements ici.

161
00:13:17,385 --> 00:13:19,890
Donc, vous remarquez que dans la suppression,

162
00:13:19,890 --> 00:13:21,830
j'ai déjà fait ce changement ici.

163
00:13:21,830 --> 00:13:27,085
Donc, après avoir enregistré les modifications aux favoris,

164
00:13:27,085 --> 00:13:29,480
nous allons ensuite rechercher les favoris, puis

165
00:13:29,480 --> 00:13:33,465
revenir après avoir rempli à la fois l'utilisateur et les plats et les favoris.

166
00:13:33,465 --> 00:13:36,505
C' est ce que notre client React attend de nous.

167
00:13:36,505 --> 00:13:38,145
Donc, même pour la suppression,

168
00:13:38,145 --> 00:13:39,995
nous allons faire les mêmes changements.

169
00:13:39,995 --> 00:13:44,115
Maintenant, avec cela, mon routeur préféré est mis à jour

170
00:13:44,115 --> 00:13:48,575
donc nous allons procéder à la mise à jour de users.js suivante.

171
00:13:48,575 --> 00:13:52,370
Enfin, nous allons mettre à jour le fichier users.js.

172
00:13:52,370 --> 00:13:57,060
Maintenant, dans le fichier users.js, nous devons ajouter

173
00:13:57,060 --> 00:14:05,245
un autre champ router.options ici,

174
00:14:05,245 --> 00:14:10,610
car parfois une demande de poste comme vous l'avez vu

175
00:14:10,610 --> 00:14:16,315
avec la connexion enverra les options d'abord pour vérifier,

176
00:14:16,315 --> 00:14:21,610
en particulier avec les voitures, si la demande de poste sera autorisée.

177
00:14:21,610 --> 00:14:30,080
C' est pourquoi nous allons vérifier bien sûr avec les options ici et ensuite

178
00:14:31,860 --> 00:14:35,450
nous allons simplement retourner

179
00:14:39,960 --> 00:14:43,045
un message d'état

180
00:14:43,045 --> 00:14:46,180
de 200 en réponse à cela.

181
00:14:46,180 --> 00:14:52,960
Pour n'importe quel point de terminaison sous utilisateurs si nous recevons les options,

182
00:14:52,960 --> 00:14:56,530
nous retournerons simplement un état 200 ici.

183
00:14:56,530 --> 00:15:03,580
Maintenant, la fonction de connexion que nous avions implémenté plus tôt,

184
00:15:03,580 --> 00:15:07,470
nous avions simplement fait passeport.authenticate

185
00:15:07,470 --> 00:15:12,930
local ici et nous avons vérifié les valeurs restantes ici.

186
00:15:12,930 --> 00:15:15,215
Maintenant, ce passeport.authenticate local,

187
00:15:15,215 --> 00:15:17,600
si l'utilisateur n'est pas authentifié,

188
00:15:17,600 --> 00:15:21,800
il renvoie simplement un non autorisé dans le message de réponse.

189
00:15:21,800 --> 00:15:28,380
Maintenant, cela peut ne pas être très significatif pour le côté client d'afficher ces informations,

190
00:15:28,380 --> 00:15:30,480
c'est pourquoi nous allons améliorer

191
00:15:30,480 --> 00:15:36,310
cette méthode de post-connexion du routeur de

192
00:15:36,310 --> 00:15:41,765
sorte que l'authentification retournera des informations plus significatives à ce stade.

193
00:15:41,765 --> 00:15:43,210
Donc, pour ce faire,

194
00:15:43,210 --> 00:15:49,395
nous ne allons pas faire le passeport.authenticate ici,

195
00:15:49,395 --> 00:15:51,955
au lieu de cela, nous allons prendre.

196
00:15:51,955 --> 00:15:55,140
Donc, laissez-moi supprimer cela à partir de là et vous verrez

197
00:15:55,140 --> 00:15:58,930
comment je vais mettre à jour le post du routeur ici.

198
00:15:58,930 --> 00:16:08,620
Donc, nous allons voir cours avec des options et ensuite nous allons inclure le req,

199
00:16:08,620 --> 00:16:12,160
res et suivant ici.

200
00:16:12,160 --> 00:16:16,885
A l'intérieur de ce req, res et ensuite ici,

201
00:16:16,885 --> 00:16:27,954
passeport.authenticate appellera ceci avec local.

202
00:16:27,954 --> 00:16:31,210
Maintenant, lorsque nous appelons ceci avec local,

203
00:16:31,210 --> 00:16:34,970
si une erreur d'authentification se produit,

204
00:16:34,970 --> 00:16:38,240
le passeport.authenticate peut être fait pour retourner

205
00:16:38,240 --> 00:16:44,230
la valeur d'erreur et aussi il retournera l'utilisateur s'il

206
00:16:44,230 --> 00:16:48,960
n'y a pas d'erreur et un troisième paramètre appelé info

207
00:16:48,960 --> 00:16:54,000
qui transportera des informations supplémentaires qui pourraient être analysées vers l'utilisateur.

208
00:16:54,000 --> 00:16:56,580
Cette erreur sera renvoyée lorsqu'il y a

209
00:16:56,580 --> 00:16:59,950
une erreur authentique qui se produit dans passeport.authenticate.

210
00:16:59,950 --> 00:17:03,400
Mais si les informations de l'utilisateur

211
00:17:03,400 --> 00:17:07,645
sont envoyées dans passeport.authenticate mais que l'utilisateur n'existe pas,

212
00:17:07,645 --> 00:17:10,490
cela n'est pas compté comme une erreur.

213
00:17:10,490 --> 00:17:14,690
Au lieu de cela, il sera compté comme l'utilisateur n'existe pas et

214
00:17:14,690 --> 00:17:19,305
que les informations sont analysées de nouveau dans l'objet info qui entre.

215
00:17:19,305 --> 00:17:21,500
Ainsi, l'erreur sera renvoyée lorsqu'il y a

216
00:17:21,500 --> 00:17:24,925
une erreur authentique qui se produit pendant le processus d'authentification,

217
00:17:24,925 --> 00:17:30,820
mais les informations contiendront des informations si l'utilisateur n'existe pas.

218
00:17:30,820 --> 00:17:36,920
Ainsi, passeport.authenticate transmet un message indiquant que

219
00:17:36,920 --> 00:17:39,575
l'utilisateur n'existe pas ou que le nom d'utilisateur

220
00:17:39,575 --> 00:17:42,850
est incorrect ou que le mot de passe est incorrect et ainsi de suite.

221
00:17:42,850 --> 00:17:46,870
Donc, cette information sera transmise dans le message d'information.

222
00:17:46,870 --> 00:17:49,230
Maintenant, nous verrons comment cela

223
00:17:49,230 --> 00:17:52,060
nous est utile lorsque nous regardons le côté client un peu plus tard.

224
00:17:52,060 --> 00:17:55,400
Donc, dans cette situation,

225
00:17:55,400 --> 00:18:01,455
nous allons gérer cela comme suit,

226
00:18:01,455 --> 00:18:06,810
et pas seulement que lorsque nous appelons ce passeport.authenticate,

227
00:18:06,810 --> 00:18:10,220
nous devons également passer dans un req

228
00:18:10,220 --> 00:18:15,080
, res, suivant comme les trois paramètres.

229
00:18:15,080 --> 00:18:20,130
Donc, c'est la structure lorsque vous devez appeler passeport.authenticate et s'attendre à

230
00:18:20,130 --> 00:18:25,270
ce qu'il vous transmette des informations comme celle-ci comme une méthode de rappel ici,

231
00:18:25,270 --> 00:18:27,630
donc vous devez également fournir ce req, res,

232
00:18:27,630 --> 00:18:30,250
suivant là aussi.

233
00:18:30,250 --> 00:18:32,270
Maintenant, si cela se produit,

234
00:18:32,270 --> 00:18:36,780
donc nous allons dire si err,

235
00:18:36,780 --> 00:18:40,425
donc s'il y a une erreur qui se produit,

236
00:18:40,425 --> 00:18:45,395
nous allons dire retourner la prochaine erreur, puis laisser

237
00:18:45,395 --> 00:18:51,480
le gestionnaire d'erreur de notre routeur express et prendre soin de cela.

238
00:18:51,480 --> 00:18:56,755
Maintenant, nous allons considérer d'autres situations, sinon l'utilisateur.

239
00:18:56,755 --> 00:18:59,630
Donc, si nous avons atteint ce point,

240
00:18:59,630 --> 00:19:02,580
cela signifie que ce n'est pas une erreur qui s'est produite,

241
00:19:02,580 --> 00:19:05,615
mais peut-être que l'utilisateur n'a pas pu être trouvé.

242
00:19:05,615 --> 00:19:07,100
Si l'utilisateur n'est pas trouvé

243
00:19:07,100 --> 00:19:11,190
, l'utilisateur ici sera défini sur null dans ce cas.

244
00:19:11,190 --> 00:19:14,634
Donc, dans cette situation,

245
00:19:14,634 --> 00:19:17,375
si l'utilisateur n'existe pas,

246
00:19:17,375 --> 00:19:23,680
alors nous devons être en mesure de transmettre des informations au côté serveur.

247
00:19:23,680 --> 00:19:28,435
Donc, ce que nous ferons, c'est que nous transmettrons cette information dans ce format.

248
00:19:28,435 --> 00:19:32,020
Donc, je vais découper ceci d'ici et

249
00:19:32,020 --> 00:19:36,640
puis coller ici et puis nous allons éditer ceci.

250
00:19:36,640 --> 00:19:40,704
Donc, si l'utilisateur est nul,

251
00:19:40,704 --> 00:19:45,830
alors nous allons renvoyer un code d'état comme 401, ce qui signifie

252
00:19:45,830 --> 00:19:53,975
non autorisé, puis nous allons renvoyer l'information succès false,

253
00:19:53,975 --> 00:19:57,405
et ensuite nous ne transmettrons pas le jeton,

254
00:19:57,405 --> 00:20:00,795
nous allons revenir le message d'état.

255
00:20:00,795 --> 00:20:03,135
Donc, ici, nous allons dire

256
00:20:03,135 --> 00:20:12,670
« Connexion sans succès » et puis la troisième information,

257
00:20:12,670 --> 00:20:18,070
nous allons passer cette information cet objet que nous avons reçu ici comme

258
00:20:18,070 --> 00:20:25,635
la troisième partie du message de réponse que nous envoyons de notre serveur ici.

259
00:20:25,635 --> 00:20:28,935
Ainsi, l'indicateur de succès sera défini sur false,

260
00:20:28,935 --> 00:20:32,385
l'état sera défini Connexion infructueuse et

261
00:20:32,385 --> 00:20:36,725
les informations d'erreur transmises dans l'information seront transmises.

262
00:20:36,725 --> 00:20:39,855
Maintenant, notez que cette situation se produira si

263
00:20:39,855 --> 00:20:43,125
le nom d'utilisateur et le mot de passe sont incorrects,

264
00:20:43,125 --> 00:20:48,600
et donc ce n'est pas une erreur dans le sens de l'erreur, mais

265
00:20:48,600 --> 00:20:54,040
le fait que l'authentification n'a pas pu trouver l'utilisateur ou le mot de passe de l'utilisateur est incorrect.

266
00:20:54,040 --> 00:20:58,530
Donc, cette information sera encodée dans l'information qui entre et de sorte que je

267
00:20:58,530 --> 00:21:04,590
reviendrai comme une erreur du côté client.

268
00:21:04,590 --> 00:21:09,615
La partie sinon

269
00:21:09,615 --> 00:21:15,355
est gérée comme req.login.

270
00:21:15,355 --> 00:21:17,220
Donc, si cela réussit,

271
00:21:17,220 --> 00:21:22,710
le passeport.authenticate nous allons ajouter cette méthode appelée req.login à l'utilisateur.

272
00:21:22,710 --> 00:21:24,340
Donc, à ce stade,

273
00:21:24,340 --> 00:21:27,950
nous allons simplement passer l'objet utilisateur que nous avons obtenu.

274
00:21:27,950 --> 00:21:31,055
Donc ici, si nous avons atteint ce point,

275
00:21:31,055 --> 00:21:36,195
cela signifie que l'objet utilisateur n'est pas nul et qu'aucune erreur n'est survenue,

276
00:21:36,195 --> 00:21:40,090
donc cela signifie que l'utilisateur peut être connecté.

277
00:21:41,080 --> 00:21:44,550
Donc, nous allons dire erreur,

278
00:21:48,960 --> 00:21:51,460
nous allons essayer de connecter l'utilisateur.

279
00:21:51,460 --> 00:21:58,000
Donc, nous allons dire si err et

280
00:21:58,000 --> 00:22:05,345
ensuite nous allons transmettre le même type d'information d'erreur que nous avons fait ici.

281
00:22:05,345 --> 00:22:09,840
Donc, dans ce cas, en cas d'erreur,

282
00:22:13,290 --> 00:22:19,430
alors nous allons passer un code d'état comme 401 et nous dirons que le succès

283
00:22:19,430 --> 00:22:25,125
est faux et le statut comme Connexion infructueuse,

284
00:22:25,125 --> 00:22:28,340
puis les informations d'erreur,

285
00:22:29,280 --> 00:22:31,840
au lieu de l'information,

286
00:22:31,840 --> 00:22:42,380
nous allons passer « Impossible de se connecter à l'utilisateur ».

287
00:22:42,380 --> 00:22:48,960
Donc, c'est le message que nous transmettrons ici si l'erreur se produit.

288
00:22:48,960 --> 00:22:53,200
Sinon, nous serions en bas ici.

289
00:22:53,200 --> 00:22:55,960
Donc, à ce stade,

290
00:22:55,960 --> 00:22:59,440
nous serions en mesure de générer le jeton.

291
00:22:59,440 --> 00:23:02,495
Donc, si nous avons atteint ce point, cela

292
00:23:02,495 --> 00:23:06,370
signifie que l'utilisateur s'est connecté avec succès,

293
00:23:06,370 --> 00:23:08,430
et donc nous pouvons maintenant générer le jeton.

294
00:23:08,430 --> 00:23:12,705
Donc, nous allons générer le jeton en fonction de l'ID de l'utilisateur,

295
00:23:12,705 --> 00:23:18,350
puis nous allons retourner le jeton à l'utilisateur.

296
00:23:18,350 --> 00:23:21,635
Donc, ici, nous allons dire le jeton var,

297
00:23:21,635 --> 00:23:30,730
puis nous pouvons dire Res.StatusCode est 200, puis le succès res.json vrai,

298
00:23:30,730 --> 00:23:33,600
donc, ce qui signifie que l'utilisateur s'est connecté avec succès.

299
00:23:33,600 --> 00:23:38,490
Donc, l'état serait la connexion réussie.

300
00:23:38,490 --> 00:23:40,605
Ensuite, la troisième partie,

301
00:23:40,605 --> 00:23:42,360
au lieu de l'erreur,

302
00:23:42,360 --> 00:23:46,200
je vais passer le jeton à l'utilisateur.

303
00:23:46,200 --> 00:23:48,760
Donc, nous allons dire jeton,

304
00:23:51,100 --> 00:23:54,675
ce jeton que nous venons d'obtenir plus tôt.

305
00:23:54,675 --> 00:24:01,030
Ainsi, ce jeton sera transmis en tant que propriété token du message de réponse.

306
00:24:01,030 --> 00:24:04,560
Donc, ici, notez que le succès est défini sur true, donc,

307
00:24:04,560 --> 00:24:08,340
ce qui signifie que l'utilisateur s'est connecté avec succès,

308
00:24:08,340 --> 00:24:12,290
et donc l'utilisateur peut continuer à ce stade.

309
00:24:12,290 --> 00:24:19,050
Cela doit être fait dans le req.login ici.

310
00:24:19,820 --> 00:24:22,970
Donc, à ce stade,

311
00:24:22,970 --> 00:24:27,180
nous allons fermer le req.login.

312
00:24:27,180 --> 00:24:33,735
Donc, notez que c'est à l'intérieur de ce req.Connectez-vous ici.

313
00:24:33,735 --> 00:24:37,320
Donc, là-dedans, nous allons passer ces trois en arrière.

314
00:24:37,320 --> 00:24:41,370
Alors, laissez-moi juste mettre ces trois lignes en retrait.

315
00:24:41,720 --> 00:24:48,850
Donc, c'est ainsi que nous gérerions la méthode de journalisation de l'utilisateur.

316
00:24:48,850 --> 00:24:52,230
Donc, encore une fois, en examinant ce code une fois de plus.

317
00:24:52,230 --> 00:24:53,950
Donc, nous allons faire la publication du routeur,

318
00:24:53,950 --> 00:24:56,815
mais au lieu de faire l'authentification du passeport juste là

319
00:24:56,815 --> 00:24:58,960
, nous allons dire req, res

320
00:24:58,960 --> 00:25:01,240
, ensuite, et puis à l'intérieur,

321
00:25:01,240 --> 00:25:04,285
nous allons faire un passeport authentifier pour le local,

322
00:25:04,285 --> 00:25:06,560
et cet authentification passera.

323
00:25:06,560 --> 00:25:09,250
Donc, nous pouvons fournir une fonction de rappel à cela,

324
00:25:09,250 --> 00:25:11,810
et cette fonction de rappel retournera soit l'erreur,

325
00:25:11,810 --> 00:25:14,730
l'utilisateur, soit les informations ici.

326
00:25:14,730 --> 00:25:16,300
Donc, si c'est une erreur,

327
00:25:16,300 --> 00:25:20,735
nous allons juste permettre au gestionnaire d'erreurs express de prendre soin de cela.

328
00:25:20,735 --> 00:25:22,730
Si l'utilisateur est nul,

329
00:25:22,730 --> 00:25:26,940
cela signifie que la connexion de l'utilisateur a échoué,

330
00:25:26,940 --> 00:25:29,730
et la raison de cela sera dans l'info.

331
00:25:29,730 --> 00:25:36,870
Donc, cela reviendra comme l'erreur info dans le message de réponse ici.

332
00:25:36,870 --> 00:25:38,790
Si nous arrivons à ce point,

333
00:25:38,790 --> 00:25:43,555
alors l'utilisateur est vérifié avec succès.

334
00:25:43,555 --> 00:25:45,400
Donc, alors nous allons nous connecter à l'utilisateur.

335
00:25:45,400 --> 00:25:47,630
Donc, le passeport authentifier,

336
00:25:47,630 --> 00:25:53,385
nous allons ajouter dans cette méthode appelée login au req, le message de demande.

337
00:25:53,385 --> 00:25:56,770
Ainsi, nous pouvons appeler la connexion avec l'utilisateur.

338
00:25:56,770 --> 00:25:59,355
Si cela renvoie une erreur,

339
00:25:59,355 --> 00:26:03,105
alors nous retournerons l'erreur ici correctement.

340
00:26:03,105 --> 00:26:08,590
Si ce n'est pas le cas, nous aurons atteint le point où l'utilisateur est authentifié avec succès.

341
00:26:08,590 --> 00:26:12,630
Ainsi, nous pouvons générer le jeton Web JSON ici, puis retourner

342
00:26:12,630 --> 00:26:18,315
le jeton Web JSON à l'utilisateur pour confirmer que l'utilisateur est correctement connecté.

343
00:26:18,315 --> 00:26:21,545
Donc, c'est l'ensemble des étapes que nous allons utiliser ici.

344
00:26:21,545 --> 00:26:25,735
Maintenant, la raison pour laquelle je fais une façon plus élaborée de le gérer est que

345
00:26:25,735 --> 00:26:30,035
je veux faire la distinction entre la situation où une véritable erreur

346
00:26:30,035 --> 00:26:34,170
se produit pendant le processus d'authentification par opposition à la situation

347
00:26:34,170 --> 00:26:39,095
où le nom d'utilisateur est invalide ou le mot de passe est invalide.

348
00:26:39,095 --> 00:26:42,860
Donc, ces deux cas seront traités par cette situation,

349
00:26:42,860 --> 00:26:46,550
où l'information nous transportera l'information.

350
00:26:46,550 --> 00:26:48,900
Donc, ce n'est pas une erreur en soi,

351
00:26:48,900 --> 00:26:52,090
mais c'est une situation où l'utilisateur

352
00:26:52,090 --> 00:26:55,710
n'est pas un utilisateur valide ou le mot de passe de l'utilisateur n'est pas valide.

353
00:26:55,710 --> 00:27:01,070
Donc, c'est ainsi que nous allons gérer le processus de connexion de l'utilisateur.

354
00:27:01,070 --> 00:27:03,660
En outre, je vais ajouter

355
00:27:03,660 --> 00:27:14,825
une autre méthode ici appelée CheckJWTToken.

356
00:27:14,825 --> 00:27:21,100
Il est tout à fait possible que le client se soit connecté et obtienne le jeton Web JSON,

357
00:27:21,100 --> 00:27:24,855
un peu plus tard, le jeton Web JSON peut expirer.

358
00:27:24,855 --> 00:27:32,840
Ainsi, si l'utilisateur tente d'accéder du côté client avec un jeton expiré au serveur,

359
00:27:32,840 --> 00:27:35,610
le serveur ne sera pas en mesure d'authentifier l'utilisateur.

360
00:27:35,610 --> 00:27:37,780
Par conséquent, à intervalles réguliers,

361
00:27:37,780 --> 00:27:42,180
nous pouvons souhaiter effectuer une vérification croisée pour nous assurer que le jeton Web JSON est toujours valide.

362
00:27:42,180 --> 00:27:44,975
Donc, c'est la raison pour laquelle j'inclus ceci,

363
00:27:44,975 --> 00:27:49,620
un autre point de terminaison appelé CheckJWTToken.

364
00:27:49,620 --> 00:27:53,155
Donc, si vous faites un accès au checkJWTToken en

365
00:27:53,155 --> 00:27:58,700
incluant le jeton dans l'en-tête d'autorisation,

366
00:27:58,700 --> 00:28:02,490
alors cet appel retournera un vrai ou faux

367
00:28:02,490 --> 00:28:06,535
pour vous indiquer si le jeton Web JSON est toujours valide ou non.

368
00:28:06,535 --> 00:28:10,930
S' il n'est pas valide, le côté client peut initier une autre connexion pour

369
00:28:10,930 --> 00:28:15,945
que l'utilisateur obtienne un nouveau jeton Web JSON si nécessaire.

370
00:28:15,945 --> 00:28:17,285
Donc, pour ce faire,

371
00:28:17,285 --> 00:28:27,109
nous dirons cors.corsWithOptions et req,

372
00:28:27,109 --> 00:28:31,385
res ici comme prévu.

373
00:28:31,385 --> 00:28:35,670
Ici, nous dirons

374
00:28:39,820 --> 00:28:49,360
passeport authentifier jwt

375
00:28:49,360 --> 00:28:57,150
et session : false,

376
00:29:00,020 --> 00:29:07,270
et cela reviendrait err, utilisateur, info.

377
00:29:09,020 --> 00:29:13,770
Donc, rappelez-vous comment nous utilisons le passeport authentifier plus tôt.

378
00:29:13,770 --> 00:29:17,195
Donc, nous appelons le JWT avec session false ici.

379
00:29:17,195 --> 00:29:21,745
Donc, plus tôt ici, nous disons passeport authentifier local.

380
00:29:21,745 --> 00:29:23,535
Donc, c'est pour l'authentification locale.

381
00:29:23,535 --> 00:29:27,330
Donc, c'est pour l'authentification JSON Web Token.

382
00:29:27,330 --> 00:29:29,430
Donc, quand nous appelons cela,

383
00:29:29,430 --> 00:29:33,435
alors puisque cela va vérifier le jeton Web JSON, donc nous dirons,

384
00:29:33,435 --> 00:29:40,335
si err retourne prochaine

385
00:29:40,335 --> 00:29:44,895
erreur, puis laissez le gestionnaire d'erreurs express prendre soin de cette situation.

386
00:29:44,895 --> 00:29:50,469
Ensuite, nous dirons, si ce n'est pas l'utilisateur,

387
00:29:53,330 --> 00:30:00,330
si l'utilisateur n'existe pas, alors de la même manière.

388
00:30:00,330 --> 00:30:03,510
Donc, ce qui signifie que si l'objet utilisateur a été

389
00:30:03,510 --> 00:30:07,810
trouvé à partir du jeton Web JSON puis chargé sur req.user,

390
00:30:07,810 --> 00:30:11,400
cela signifie que l'utilisateur est un utilisateur valide

391
00:30:11,400 --> 00:30:13,485
et peut donc être autorisé à poursuivre.

392
00:30:13,485 --> 00:30:20,330
Sinon, nous allons dire que l'utilisateur n'existe pas.

393
00:30:20,330 --> 00:30:24,995
Donc, nous devons informer que le jeton Web JSON a expiré.

394
00:30:24,995 --> 00:30:26,180
Donc, à ce stade,

395
00:30:26,180 --> 00:30:29,090
nous allons envoyer une res avec

396
00:30:29,090 --> 00:30:36,545
un code d'état de 401.

397
00:30:36,545 --> 00:30:47,130
Donc, non autorisé, setHeader, Content-Type,

398
00:30:49,900 --> 00:30:56,280
application/json, et puis nous retournerons res.

399
00:30:58,680 --> 00:31:13,750
Res.json dira état JWT

400
00:31:13,750 --> 00:31:17,090
invalide et ensuite,

401
00:31:17,730 --> 00:31:23,690
nous retournerons un drapeau appelé success falls et ensuite,

402
00:31:23,880 --> 00:31:29,080
nous retournerons les informations que nous obtenons si l'utilisateur

403
00:31:29,080 --> 00:31:34,460
n'est pas authentifié comme l'erreur à ce stade.

404
00:31:36,420 --> 00:31:40,480
Sinon, cela signifie que nous avons atteint ce point,

405
00:31:40,480 --> 00:31:43,220
alors l'utilisateur est un utilisateur valide.

406
00:31:43,220 --> 00:31:44,850
Donc, dans ce cas,

407
00:31:44,850 --> 00:31:47,230
laissez-moi juste copier ce code ici,

408
00:31:47,230 --> 00:31:54,070
nous allons envoyer un code d'état de 200, puis le res.json,

409
00:31:54,070 --> 00:32:02,720
enverra JWT valide et réussi étant vrai.

410
00:32:02,940 --> 00:32:09,820
La troisième partie, nous enverrons les informations de l'utilisateur.

411
00:32:09,820 --> 00:32:16,000
Ainsi, lorsque ce point de terminaison est appelé avec la méthode get,

412
00:32:16,000 --> 00:32:19,170
cela vérifiera si le jeton est valide ou non.

413
00:32:19,170 --> 00:32:20,220
Si le jeton est valide,

414
00:32:20,220 --> 00:32:24,020
alors vous recevrez cette réponse et de l'indicateur de succès dans la réponse,

415
00:32:24,020 --> 00:32:27,770
vous pouvez vérifier si le jsonwebtoken est valide ou non.

416
00:32:27,770 --> 00:32:32,155
Ceci est utile du côté client.

417
00:32:32,155 --> 00:32:37,825
Maintenant, ce passeport authentifier ici devra être fourni

418
00:32:37,825 --> 00:32:43,790
avec req et res comme les deux paramètres ici.

419
00:32:43,790 --> 00:32:47,630
Donc, c'est comme ça que nous appelons l'authentification du passeport.

420
00:32:47,630 --> 00:32:49,355
Donc, notez que chaque fois que vous appelez

421
00:32:49,355 --> 00:32:52,840
passeport authentifier et que

422
00:32:52,840 --> 00:33:01,825
vous attendez cette fonction de rappel ici, vous devez ajouter à ce point req.res au passeport authentifier à l'arrière ici.

423
00:33:01,825 --> 00:33:03,890
Dans notre serveur d'API de repos,

424
00:33:03,890 --> 00:33:07,490
nous avions implémenté nos commentaires de telle sorte que les commentaires

425
00:33:07,490 --> 00:33:12,245
formaient des sous-documents à l'intérieur du document du dishe, de

426
00:33:12,245 --> 00:33:16,540
sorte qu'ils achètent chaque plat inclus son propre ensemble de commentaires.

427
00:33:16,540 --> 00:33:19,520
Mais la façon dont nous avons implémenté notre client React est

428
00:33:19,520 --> 00:33:22,965
telle que les commentaires sont conservés indépendamment des plats,

429
00:33:22,965 --> 00:33:27,680
et les commentaires eux-mêmes portaient l'ID de plat correspondant.

430
00:33:27,680 --> 00:33:30,400
Maintenant, ce sont deux façons différentes d'

431
00:33:30,400 --> 00:33:34,445
implémenter le côté serveur ainsi que le côté client.

432
00:33:34,445 --> 00:33:39,685
Dans l'application Angular que nous sommes implémentés dans notre spécialisation Angular,

433
00:33:39,685 --> 00:33:43,470
nous avions utilisé la méthode de sous-document pour

434
00:33:43,470 --> 00:33:47,560
gérer les commentaires dans notre application client Angular.

435
00:33:47,560 --> 00:33:50,050
Ainsi, le serveur d'API restante a été

436
00:33:50,050 --> 00:33:54,090
implémenté de telle sorte qu'il était plus approprié pour le client Angular.

437
00:33:54,090 --> 00:34:00,600
Mais pour les clients React puisque nous avons gardé les commentaires indépendants des plats,

438
00:34:00,600 --> 00:34:03,985
puis utiliser l'ID plat à l'intérieur du commentaire,

439
00:34:03,985 --> 00:34:09,300
nous devons donc restructurer notre serveur API de repos,

440
00:34:09,300 --> 00:34:16,835
donc c'est que nous avons un point de terminaison de commentaire séparé indépendant du point de terminaison de plats.

441
00:34:16,835 --> 00:34:22,310
Donc, nous devons restructurer notre code dans le serveur

442
00:34:22,310 --> 00:34:29,140
pour introduire le point de terminaison de l'API REST /comments à ce stade.

443
00:34:29,140 --> 00:34:30,600
Donc, pour ce faire,

444
00:34:30,600 --> 00:34:37,540
allons de l'avant et implémentons un nouveau modèle appelé comment.js.

445
00:34:37,540 --> 00:34:39,260
Donc, en allant dans les modèles,

446
00:34:39,260 --> 00:34:45,790
permettez-moi d'implémenter un nouveau fichier nommé comments.js.

447
00:34:47,220 --> 00:34:50,015
Dans le fichier comments.js,

448
00:34:50,015 --> 00:34:56,110
nous allons déplacer le CommentSchema du

449
00:34:56,110 --> 00:35:02,660
fichier dishes.js dans le fichier comments.js, puis le supprimer complètement du fichier dishes.js.

450
00:35:02,660 --> 00:35:03,900
Mais avant de le faire,

451
00:35:03,900 --> 00:35:08,770
nous devons copier le mongoose et le schéma d'ici,

452
00:35:08,770 --> 00:35:13,860
alors laissez-moi simplement copier ceci de dishes.js dans comment.js.

453
00:35:13,860 --> 00:35:16,590
Après cela, en allant dans dishes.js,

454
00:35:16,590 --> 00:35:21,040
laissez-moi couper ce CommentSchema complètement à partir d'ici,

455
00:35:21,040 --> 00:35:28,300
parce que nous aurons ceci séparément dans le modèle de commentaires ici.

456
00:35:28,300 --> 00:35:33,070
Donc, déplacons cela dans le modèle de commentaires, puis collez-le ici.

457
00:35:33,070 --> 00:35:35,050
Mais bien sûr, ce n'est pas complet,

458
00:35:35,050 --> 00:35:37,870
nous allons mettre à jour un peu le CommentSchema.

459
00:35:37,870 --> 00:35:39,300
Mais avant de le faire,

460
00:35:39,300 --> 00:35:43,455
revenez au fichier dishes.js et dans le fichier vaisselle,

461
00:35:43,455 --> 00:35:47,925
nous allons supprimer les commentaires du Dish.Schema,

462
00:35:47,925 --> 00:35:51,510
parce que nous allons stocker le contenu séparément des

463
00:35:51,510 --> 00:35:55,550
plats dans cette version de notre serveur.

464
00:35:55,550 --> 00:36:00,450
Donc, c'est ainsi que nous allons mettre à jour le modèle de plats ici.

465
00:36:00,450 --> 00:36:08,180
Donc, nous avons complètement supprimé les commentaires du modèle de vaisselle ici.

466
00:36:08,180 --> 00:36:10,270
Entrer dans le modèle de commentaires,

467
00:36:10,270 --> 00:36:15,355
donc nous voyons maintenant que nous avons le CommentSchema implémenté ici.

468
00:36:15,355 --> 00:36:19,525
Mais en outre, dans le CommentsChema,

469
00:36:19,525 --> 00:36:23,330
nous devons maintenant pointer explicitement vers

470
00:36:23,330 --> 00:36:28,885
le plat spécifique pour lequel ce commentaire est le commentaire correspondant.

471
00:36:28,885 --> 00:36:30,700
Maintenant, c'est là que

472
00:36:30,700 --> 00:36:37,435
notre population de mangoustes et

473
00:36:37,435 --> 00:36:41,580
la façon dont nous stockons les identifiants d'objets viennent à notre secours.

474
00:36:41,580 --> 00:36:45,860
Donc, nous allons mettre à jour le CommentSchema disant que nous aurons la note,

475
00:36:45,860 --> 00:36:47,800
le commentaire et l'auteur ici.

476
00:36:47,800 --> 00:36:49,110
En plus de l'auteur,

477
00:36:49,110 --> 00:36:56,080
nous allons introduire un champ de plus appelé comme le plat ici qui est

478
00:36:56,080 --> 00:37:05,540
du type : Mongoose.Schema types.Objectid,

479
00:37:06,390 --> 00:37:19,870
et donc cela se référera au plat ici.

480
00:37:19,870 --> 00:37:29,060
Donc, ce serait une référence d'objet au modèle plat ici,

481
00:37:29,060 --> 00:37:32,255
et donc avec cette modification maintenant

482
00:37:32,255 --> 00:37:36,640
nos commentaires contiendront le champ d'évaluation, le champ de commentaire,

483
00:37:36,640 --> 00:37:42,355
l'auteur qui est à nouveau une référence à l'utilisateur correspondant,

484
00:37:42,355 --> 00:37:47,660
puis le champ plat qui est une référence au plat ici.

485
00:37:47,660 --> 00:37:50,060
Donc, ce qui signifie que nous allons maintenant devoir

486
00:37:50,060 --> 00:37:53,640
remplir les commentaires avec l'auteur et le champ de plat.

487
00:37:53,640 --> 00:37:55,565
Une fois que nous avons terminé cela,

488
00:37:55,565 --> 00:38:01,585
alors nous dirons var Comments

489
00:38:01,585 --> 00:38:09,910
mongoose.model et nous appellerons ce 'Commentaire',

490
00:38:09,910 --> 00:38:16,765
puis cela utilise le CommentSchema que nous venons de définir ici,

491
00:38:16,765 --> 00:38:21,970
et ensuite nous devons exporter ceci à partir d'ici,

492
00:38:21,970 --> 00:38:25,280
les commentaires.model d'ici.

493
00:38:25,280 --> 00:38:28,395
Donc, maintenant que nous avons introduit le comments.model,

494
00:38:28,395 --> 00:38:35,045
alors nous allons aller de l'avant et ensuite introduire un nouveau routeur appelé commentUter.

495
00:38:35,045 --> 00:38:37,060
Donc, pour introduire le routeur de commentaires,

496
00:38:37,060 --> 00:38:39,630
allons dans les routes ici,

497
00:38:39,630 --> 00:38:45,990
puis créer un nouveau fichier nommé commentRouter.js.

498
00:38:47,090 --> 00:38:52,415
Dans le commentRouter.js, laissez-moi copier quelques choses

499
00:38:52,415 --> 00:38:59,890
à partir du Dish.Router.

500
00:38:59,890 --> 00:39:07,720
Donc, nous aurons ces commentaires ici,

501
00:39:07,720 --> 00:39:14,865
alors laissez-moi copier ces choses de la et aussi,

502
00:39:14,865 --> 00:39:21,070
pendant que je suis à elle, laissez-moi simplement les copier aussi jusqu'à ce point,

503
00:39:21,070 --> 00:39:24,625
et puis je vais mettre à jour cela un peu plus tard.

504
00:39:24,625 --> 00:39:26,680
Donc, en entrant dans le commentUter,

505
00:39:26,680 --> 00:39:28,040
nous avons besoin de toutes ces parties,

506
00:39:28,040 --> 00:39:33,640
donc nous allons dire Com, Express, BodyParser, mongoose,

507
00:39:33,640 --> 00:39:37,735
authentifier, cors, et ensuite nous allons

508
00:39:37,735 --> 00:39:46,490
importer des commentaires à partir de modèles/commentaires.

509
00:39:49,950 --> 00:40:00,460
Ensuite, nous appellerons ceci comme le commentrouter qui est un Express.Router ici.

510
00:40:02,060 --> 00:40:11,950
Ensuite, nous dirons CommentUter utiliser BodyParser,

511
00:40:11,950 --> 00:40:17,915
et puis cela deviendrait maintenant la route CommentUter.

512
00:40:17,915 --> 00:40:22,030
Maintenant, nous devons aller dans le Dish.Router, puis

513
00:40:22,030 --> 00:40:27,200
supprimer toutes les parties qui se réfère aux commentaires ici.

514
00:40:27,200 --> 00:40:34,330
Donc, laissez-moi juste découper cette partie et ensuite nous les réutiliserons pour notre CommentUter.

515
00:40:34,330 --> 00:40:38,200
Donc, tout cela ne sont plus nécessaires dans le Dish.Router.

516
00:40:38,200 --> 00:40:42,080
Donc, je vais supprimer tout cela du Dish.Router ici,

517
00:40:42,080 --> 00:40:43,770
alors laissez-moi les découper,

518
00:40:43,770 --> 00:40:48,715
tout ce qui concerne la route des commentaires du Dish.Router,

519
00:40:48,715 --> 00:40:50,770
puis nous allons dans le commentUter,

520
00:40:50,770 --> 00:40:54,405
puis laissez-moi aller de l'avant et coller cela en place ici,

521
00:40:54,405 --> 00:40:57,100
puis nous allons éditer cela ici.

522
00:40:57,100 --> 00:41:02,660
Ensuite, nous devons exporter le commentUter.

523
00:41:05,160 --> 00:41:08,205
Donc, va exporter le commentrouter pour nous.

524
00:41:08,205 --> 00:41:12,060
Mais bien sûr, ce code n'est pas complètement exact.

525
00:41:12,060 --> 00:41:14,995
Donc, nous devons aller de l'avant et corriger ce code ici.

526
00:41:14,995 --> 00:41:16,585
Donc, pour ce code,

527
00:41:16,585 --> 00:41:20,180
nous nous rendons compte maintenant que ce n'est pas la route Dish.Router,

528
00:41:20,180 --> 00:41:21,785
au lieu de cela devrait être

529
00:41:21,785 --> 00:41:27,700
le /endpoint car nous

530
00:41:27,700 --> 00:41:33,685
allons le monter dans le point de terminaison /comments ici.

531
00:41:33,685 --> 00:41:35,685
Donc, nous allons dire commentUter,

532
00:41:35,685 --> 00:41:39,859
puis les options CorsWithOptions (req,

533
00:41:39,859 --> 00:41:42,550
res) qui reste en tant que telles là,

534
00:41:42,550 --> 00:41:48,429
puis le get cors.cors puis req.res,

535
00:41:48,429 --> 00:41:52,460
puis celui-ci deviendra des commentaires.

536
00:41:53,880 --> 00:41:58,430
FindById, req.

537
00:42:00,600 --> 00:42:05,330
Donc, ce serait commentaires.find

538
00:42:07,050 --> 00:42:17,080
et req.query ici.

539
00:42:17,080 --> 00:42:20,920
Donc, lorsque les commentaires sont trouvés

540
00:42:20,920 --> 00:42:22,974
, alors, à ce stade,

541
00:42:22,974 --> 00:42:25,940
nous allons remplir l'auteur,

542
00:42:26,880 --> 00:42:30,430
déjà là, remplir ici.

543
00:42:30,430 --> 00:42:33,380
Donc, je vais juste supprimer ce commentaires.author, et puis,

544
00:42:33,380 --> 00:42:37,410
nous allons simplement remplir l'auteur ici.

545
00:42:37,410 --> 00:42:44,425
Ensuite, cela nous donnerait des commentaires ici.

546
00:42:44,425 --> 00:42:49,310
Ensuite, nous dirons, cela peut être simplifié de manière significative.

547
00:42:49,310 --> 00:42:53,835
Donc, l'erreur de capture est là de toute façon.

548
00:42:53,835 --> 00:43:00,805
Donc, quand le commentaire arrivera, il reviendra simplement.

549
00:43:00,805 --> 00:43:03,910
Désolé, ça devrait l'être.

550
00:43:03,910 --> 00:43:06,525
Donc, si pour le get,

551
00:43:06,525 --> 00:43:09,305
quand nous obtenons les commentaires,

552
00:43:09,305 --> 00:43:13,760
commentaires.Trouver req.query, .populate auteur ici,

553
00:43:13,760 --> 00:43:18,010
et puis, nous allons dire, .then commentaires,

554
00:43:18,010 --> 00:43:21,619
et puis, nous dirons, RES.StatusCode 200,

555
00:43:21,619 --> 00:43:27,605
setHeader, puis, nous allons retourner les commentaires d'ici,

556
00:43:27,605 --> 00:43:30,850
res.json commentaires d'ici.

557
00:43:30,850 --> 00:43:36,970
Maintenant, je ne remplis pas les plats ici parce que je n'ai pas explicitement besoin de

558
00:43:36,970 --> 00:43:45,300
la vaisselle comme j'utilise cette information dans mon client de réaction.

559
00:43:45,300 --> 00:43:46,840
Je n'ai besoin que de l'ID plat,

560
00:43:46,840 --> 00:43:49,085
et l'ID plat est déjà présent là,

561
00:43:49,085 --> 00:43:55,310
et c'est assez bon pour que je puisse utiliser ces données dans mon client de réaction.

562
00:43:55,310 --> 00:43:57,685
Donc, je vais le laisser en tant que tel là.

563
00:43:57,685 --> 00:43:59,530
Je vais seulement renseigner les informations de

564
00:43:59,530 --> 00:44:02,910
l'auteur là-bas parce que nous avons besoin de l'information complète de l'auteur

565
00:44:02,910 --> 00:44:08,930
chaque fois que nous rendons un élément de commentaire dans notre client de réaction.

566
00:44:08,930 --> 00:44:12,655
Donc, le get sera mis à jour comme ceci ici.

567
00:44:12,655 --> 00:44:22,015
Pour le post CorsWithOptions,

568
00:44:22,015 --> 00:44:26,070
nous dirons, Authenticate.VerifyUser req, res, suivant.

569
00:44:26,070 --> 00:44:29,540
Évidemment, pour qu'un commentaire soit publié,

570
00:44:29,540 --> 00:44:38,315
vous devez que l'auteur soit un utilisateur connecté valide.

571
00:44:38,315 --> 00:44:42,910
Seulement alors, vous autoriserez l'utilisateur à poster un commentaire.

572
00:44:42,910 --> 00:44:49,020
Ensuite, le commentaire lui-même vient dans le corps du message de demande entrante.

573
00:44:49,020 --> 00:44:51,810
Donc, d'abord, nous allons vérifier le corps

574
00:44:51,810 --> 00:44:58,865
pour nous assurer que le commentaire est inclus dans le corps ici.

575
00:44:58,865 --> 00:45:03,730
Donc, ici, je vais supprimer toutes ces parties, puis,

576
00:45:03,730 --> 00:45:06,100
simplifier davantage, et ensuite,

577
00:45:06,100 --> 00:45:09,430
nous allons implémenter cela correctement là.

578
00:45:09,430 --> 00:45:17,755
Donc, à ce stade, nous dirons,

579
00:45:17,755 --> 00:45:27,465
si req.body n'est pas égal à null,

580
00:45:27,465 --> 00:45:35,030
ce qui signifie qu'il y a un commentaire qui est enfermé à l'intérieur du corps.

581
00:45:37,380 --> 00:45:45,025
Donc, laissez-moi couper ceci et déplacer ceci dans la partie if ici,

582
00:45:45,025 --> 00:45:47,155
et ensuite, nous allons éditer ça ici.

583
00:45:47,155 --> 00:45:52,245
Donc, si le corps n'existe pas,

584
00:45:52,245 --> 00:45:56,140
alors nous allons provoquer une erreur.

585
00:45:56,140 --> 00:46:01,220
Donc, nous dirons, err nouvelle erreur,

586
00:46:01,500 --> 00:46:08,965
Commentaire introuvable dans le corps de la requête.

587
00:46:08,965 --> 00:46:12,440
Donc, nous allons soulever cette erreur ici.

588
00:46:12,450 --> 00:46:16,425
L' état de l'erreur est 404.

589
00:46:16,425 --> 00:46:20,385
Ensuite, nous dirons, retournez l'erreur suivante.

590
00:46:20,385 --> 00:46:26,560
Donc, gérons la partie erreur ici si le corps

591
00:46:26,560 --> 00:46:33,280
ne contient pas les informations de commentaire appropriées.

592
00:46:33,280 --> 00:46:35,450
S' il contient, alors, bien sûr,

593
00:46:35,450 --> 00:46:38,170
ce que nous ferons ensuite est,

594
00:46:38,170 --> 00:46:48,310
nous dirons, req.body.author est req.user. _id.

595
00:46:50,420 --> 00:46:55,610
La raison pour laquelle nous faisons cela est que nous nous souvenons que s'il s'

596
00:46:55,610 --> 00:46:59,950
agit d'un utilisateur enregistré et que l'utilisateur s'est connecté,

597
00:46:59,950 --> 00:47:03,050
alors req.user contiendra les informations utilisateur.

598
00:47:03,050 --> 00:47:07,260
Donc, je n'ai besoin que de l'ID de l'utilisateur actuellement connecté.

599
00:47:07,260 --> 00:47:10,310
Donc, nous allons dire, req.user. _id, puis,

600
00:47:10,310 --> 00:47:14,645
nous allons définir req.body.author sur req.user. _id.

601
00:47:14,645 --> 00:47:20,070
Maintenant, l'utilisateur de vérification s'assurera automatiquement que si vous atterrissez à ce stade,

602
00:47:20,070 --> 00:47:25,710
alors vous auriez évidemment un utilisateur qui s'est connecté correctement.

603
00:47:25,710 --> 00:47:28,605
Sinon, cela aurait déjà causé le problème là-bas.

604
00:47:28,605 --> 00:47:30,260
Ainsi, lorsque vous atteignez à ce stade,

605
00:47:30,260 --> 00:47:37,660
vous auriez un utilisateur valide qui s'est déjà connecté au système.

606
00:47:37,660 --> 00:47:43,460
Donc, c'est là que vous seriez en mesure de le faire maintenant.

607
00:47:43,460 --> 00:47:46,040
Donc, ce que nous faisons est que le champ auteur,

608
00:47:46,040 --> 00:47:50,625
nous le définissons explicitement dans l'ID de l'utilisateur ici afin que

609
00:47:50,625 --> 00:47:57,490
le req.body contienne les parties restantes du commentaire.

610
00:47:57,490 --> 00:48:01,315
Donc, comme vous le savez, le commentaire contient la note,

611
00:48:01,315 --> 00:48:04,540
le commentaire lui-même, et l'auteur, et les champs de plat.

612
00:48:04,540 --> 00:48:11,510
Ainsi, les parties restantes auraient dû être remplies par l'utilisateur.

613
00:48:11,510 --> 00:48:14,730
La note, le commentaire

614
00:48:14,730 --> 00:48:17,775
et les informations sur le plat doivent déjà être remplis

615
00:48:17,775 --> 00:48:20,840
dans le corps du message de demande entrante.

616
00:48:20,840 --> 00:48:23,460
La partie auteur est laissée vide là,

617
00:48:23,460 --> 00:48:28,380
que nous allons explicitement insérer à ce stade dans le corps ici.

618
00:48:28,380 --> 00:48:32,515
Donc, maintenant, req.body contiendra toutes les informations de commentaire.

619
00:48:32,515 --> 00:48:34,440
Donc, à ce stade,

620
00:48:34,440 --> 00:48:43,400
au lieu de faire cela, nous dirons, commentaires.Créer.

621
00:48:44,550 --> 00:48:49,940
En utilisant req.body, nous allons créer les commentaires ici.

622
00:48:50,010 --> 00:48:53,304
Ensuite, cela retournera

623
00:48:53,304 --> 00:48:58,735
le commentaire correspondant au commentaire que nous venons d'insérer ici.

624
00:48:58,735 --> 00:49:00,755
Maintenant, une fois que le commentaire est revenu,

625
00:49:00,755 --> 00:49:07,050
alors nous devrions faire commentaires.findById.

626
00:49:07,050 --> 00:49:09,680
Maintenant, la raison pour laquelle nous devons le faire est que nous devons

627
00:49:09,680 --> 00:49:13,070
remplir les informations de l'auteur ici.

628
00:49:13,780 --> 00:49:18,144
Donc, nous allons dire, FindById commentaires. _id,

629
00:49:18,144 --> 00:49:26,155
puis, nous allons remplir les informations de l'auteur dans le commentaire lui-même.

630
00:49:26,155 --> 00:49:34,610
Ensuite, nous allons dire, puis commenter.

631
00:49:36,570 --> 00:49:41,115
Maintenant, évidemment, ici, vous constaterez que le commentaire

632
00:49:41,115 --> 00:49:44,880
existera parce que nous venons d'insérer ce commentaire en place là-bas.

633
00:49:44,880 --> 00:49:54,470
Donc, ici, nous allons simplement retourner, RES.StatusCode est 200,

634
00:49:54,900 --> 00:50:10,040
RES.setHeader est Content-Type, application/json.

635
00:50:14,610 --> 00:50:18,430
Le commentaire lui-même dira, res.json, puis,

636
00:50:18,430 --> 00:50:21,745
retourner le commentaire à ce stade.

637
00:50:21,745 --> 00:50:26,255
Donc, c'est la façon dont nous allons gérer l'insertion d'

638
00:50:26,255 --> 00:50:30,805
un nouveau commentaire dans notre côté client ici.

639
00:50:30,805 --> 00:50:33,925
Pour le mettre, comme vous vous rendez compte,

640
00:50:33,925 --> 00:50:38,360
vous ne serez pas en mesure de faire un put sur les /comments/ points de fin.

641
00:50:38,360 --> 00:50:47,610
Donc, nous dirons, l'opération PUT n'est pas prise en charge sur le point final /comments/.

642
00:50:52,050 --> 00:50:56,180
C' est le but. C'est le message que tu reviendras.

643
00:50:56,180 --> 00:50:58,570
Donc, StatusCode est 403,

644
00:50:58,570 --> 00:51:02,610
puis, l'opération PUT n'est pas prise en charge sur /comments/.

645
00:51:02,610 --> 00:51:05,260
Maintenant, quand nous faisons une suppression,

646
00:51:13,230 --> 00:51:22,840
laissez-moi juste couper cela d'ici, et puis, nous dirons,

647
00:51:30,440 --> 00:51:32,835
commentaires.Supprimer.

648
00:51:32,835 --> 00:51:37,710
écrit vide. Ainsi, lorsque vous effectuez une suppression sur le point de terminaison des commentaires barre oblique,

649
00:51:37,710 --> 00:51:40,990
vous supprimez tous les commentaires de votre système.

650
00:51:40,990 --> 00:51:43,680
Donc, c'est une opération très dangereuse, et donc,

651
00:51:43,680 --> 00:51:48,990
vous ne devriez pas faire cela normalement.

652
00:51:48,990 --> 00:51:53,860
Donc, nous allons seulement permettre à l'administrateur d'effectuer une telle opération.

653
00:51:53,860 --> 00:51:59,410
Donc, nous allons supprimer tous les commentaires à partir de là.

654
00:51:59,410 --> 00:52:01,940
Donc, lorsque vous obtenez la réponse,

655
00:52:01,940 --> 00:52:07,700
alors nous dirons RES.StatusCode 200.

656
00:52:07,700 --> 00:52:11,080
Alors, laissez-moi juste copier ces parties ici,

657
00:52:12,090 --> 00:52:18,130
et ensuite venir les coller ici.

658
00:52:18,130 --> 00:52:21,330
Donc, nous allons dire, commentaires.remove.

659
00:52:21,330 --> 00:52:30,480
Ensuite, répondez à l'application res.StatusCode 200 json et ensuite res.json (réponse) ici.

660
00:52:30,480 --> 00:52:33,100
Donc, c'est comme ça que nous gérons la suppression.

661
00:52:33,100 --> 00:52:37,280
Opération de suppression sur le point de terminaison des commentaires barre oblique.

662
00:52:37,280 --> 00:52:43,135
Maintenant, la route suivante est le routeur de commentaires.

663
00:52:43,135 --> 00:52:49,490
Donc, ici, nous allons dire commentrouter.route et

664
00:52:49,490 --> 00:52:56,820
le point final ici serait la barre oblique commentID.

665
00:53:01,190 --> 00:53:05,580
Donc, ici les options resteront en tant que telles.

666
00:53:05,580 --> 00:53:09,760
Ensuite, pour obtenir sur le routeur actuel,

667
00:53:09,760 --> 00:53:20,455
pour le get nous dirons, commentaires.findById (req.params.

668
00:53:20,455 --> 00:53:25,040
Ce serait commentID.

669
00:53:25,380 --> 00:53:31,029
Donc, une fois que nous avons trouvé le commentaire spécifique,

670
00:53:31,029 --> 00:53:37,525
alors nous allons remplir juste l'auteur à partir de là.

671
00:53:37,525 --> 00:53:39,985
Ensuite, une fois que vous remplissez l'auteur,

672
00:53:39,985 --> 00:53:45,830
nous dirons, puis commencerons.

673
00:53:47,880 --> 00:53:51,310
Maintenant, toute cette partie est inutile ici,

674
00:53:51,310 --> 00:53:54,440
donc je vais juste supprimer la partie.

675
00:53:54,480 --> 00:54:00,985
Ce n'est pas non plus la chose appropriée ici.

676
00:54:00,985 --> 00:54:04,540
Alors, laissez-moi renommer le code.

677
00:54:04,540 --> 00:54:08,990
Donc, nous allons dire pour obtenir des commentaires.FindById,

678
00:54:11,550 --> 00:54:15,385
puis remplir l'auteur,

679
00:54:15,385 --> 00:54:20,365
puis commenter, RES.StatusCode est 200, setHeader.

680
00:54:20,365 --> 00:54:22,435
Ensuite, les autres sont Json.

681
00:54:22,435 --> 00:54:29,960
Nous reviendrons simplement les commentaires ici.

682
00:54:39,240 --> 00:54:46,750
Donc, nous allons retourner le commentaire à ce stade, res.json (commentaire).

683
00:54:46,750 --> 00:54:49,340
Vous trouverez le commentaire spécifique,

684
00:54:49,340 --> 00:54:52,415
puis retournez ce commentaire pour le post.

685
00:54:52,415 --> 00:54:55,185
Pour la post-opération, comme vous le savez,

686
00:54:55,185 --> 00:54:56,900
la post-opération n'est pas

687
00:54:56,900 --> 00:55:06,740
autorisée sur les commentaires commentID.

688
00:55:10,080 --> 00:55:13,805
Donc, c'est le message que nous allons envoyer,

689
00:55:13,805 --> 00:55:19,110
opération POST non supportée sur les commentaires barre oblique commentID.

690
00:55:19,110 --> 00:55:23,640
Donc, c'est le message que nous dirons pour la mise.

691
00:55:23,640 --> 00:55:33,730
Maintenant, pour le mettre, nous dirons commentaires.Trouver où Id (req.params.commentID).

692
00:55:34,890 --> 00:55:39,230
Donc, nous allons trouver le commentaire là,

693
00:55:40,890 --> 00:55:48,070
et il commentaire, donc pour le mettre.

694
00:55:48,070 --> 00:55:50,805
Donc, nous allons trouver le commentaire là,

695
00:55:50,805 --> 00:55:53,400
et ensuite nous dirons pour les commentaires.

696
00:55:53,400 --> 00:55:55,305
Donc, si nous trouvons le commentaire,

697
00:55:55,305 --> 00:56:07,080
si le commentaire n'est pas nul,

698
00:56:07,080 --> 00:56:19,455
alors nous allons également vérifier si comment.author.

699
00:56:19,455 --> 00:56:32,625
Si ce n'est pas le cas, commenter.arthur est égal (req.user. _id).

700
00:56:32,625 --> 00:56:38,095
Donc, nous recoupons pour nous assurer que

701
00:56:38,095 --> 00:56:43,755
le comments.author est le même que l'utilisateur actuel.

702
00:56:43,755 --> 00:56:50,950
Seul l'utilisateur actuel qui est connecté - si l'utilisateur est le même que l'auteur des commentaires

703
00:56:50,950 --> 00:56:53,760
, l'utilisateur sera autorisé à mettre à jour.

704
00:56:53,760 --> 00:56:57,190
Donc, c'est la première chose que nous allons vérifier.

705
00:56:57,190 --> 00:57:01,900
Donc, commentaires, puis commentaires.author.equal à rec.user. _id.

706
00:57:01,900 --> 00:57:07,860
Si ce n'est pas le cas, vous direz que vous n'êtes pas autorisé à mettre à jour ce commentaire.

707
00:57:07,860 --> 00:57:10,859
Comme vous voyez le .403,

708
00:57:10,859 --> 00:57:13,090
puis retournez l'erreur suivante ici.

709
00:57:13,090 --> 00:57:16,705
Donc, nous allons créer l'erreur là.

710
00:57:16,705 --> 00:57:21,800
Ensuite, après cela, nous dirons

711
00:57:29,910 --> 00:57:36,860
req.body.author, req.user. _id,

712
00:57:40,010 --> 00:57:42,215
c'est important.

713
00:57:42,215 --> 00:57:45,580
Maintenant, ces deux ne sont pas nécessaires ici,

714
00:57:45,580 --> 00:57:51,385
parce que nous sauvegardons directement le commentaire.

715
00:57:51,385 --> 00:58:05,980
Ensuite, les pilules, nous dirons commentaires.findByidAndUpdate,

716
00:58:05,980 --> 00:58:14,965
et req.params.commentID.

717
00:58:14,965 --> 00:58:18,395
Donc, nous trouverons ce commentaire spécifique,

718
00:58:18,395 --> 00:58:21,925
car nous avons déjà reçu l'ID de commentaire.

719
00:58:21,925 --> 00:58:27,205
Donc, nous allons faire des commentaires findById req.params.commentId.

720
00:58:27,205 --> 00:58:30,260
Ensuite, nous dirons alors (commentaire).

721
00:58:32,730 --> 00:58:38,705
Lorsque vous fournissez le req.params.commentID,

722
00:58:38,705 --> 00:58:42,275
nous devrons fournir explicitement le deuxième paramètre, ce

723
00:58:42,275 --> 00:58:45,825
qui est ce que nous voulons changer.

724
00:58:45,825 --> 00:58:52,285
Donc, nous dirons $set : req.body.

725
00:58:52,285 --> 00:58:54,970
Donc, le deuxième paramètre, essentiellement,

726
00:58:54,970 --> 00:58:58,740
vous indique quelle partie vous changez.

727
00:58:58,740 --> 00:59:03,710
Maintenant, puisque nous avons reçu le corps contenant le commentaire mis à jour,

728
00:59:03,710 --> 00:59:09,140
nous allons juste mettre à jour le commentaire entier lui-même.

729
00:59:09,510 --> 00:59:18,205
Ensuite, l'autre partie que nous demanderons est nouvelle : vraie.

730
00:59:18,205 --> 00:59:23,240
Ainsi, cela garantira que le commentaire mis à jour sera retourné dans

731
00:59:23,240 --> 00:59:29,815
le den de cet appel aux commentaires.findByidAndUpdate.

732
00:59:29,815 --> 00:59:32,565
Donc, nous allons dire ensuite commentaires.

733
00:59:32,565 --> 00:59:35,214
Lorsque ce commentaire est retourné,

734
00:59:35,214 --> 00:59:38,440
nous dirons Comments.findById (commentaire. _id).

735
00:59:46,200 --> 00:59:51,460
Ensuite, renseignez l'auteur là.

736
00:59:51,460 --> 00:59:53,785
Nous allons remplir l'auteur là,

737
00:59:53,785 --> 00:59:58,490
puis nous dirons ensuite commentaire.

738
00:59:58,700 --> 01:00:09,680
Donc, vous voyez que nous allons obtenir le commentaire, puis retourner le commentaire à ce stade.

739
01:00:09,680 --> 01:00:13,095
Donc, c'est ainsi que nous allons mettre à jour le commentaire.

740
01:00:13,095 --> 01:00:17,395
Donc, c'est la situation où le commentaire n'est pas nul.

741
01:00:17,395 --> 01:00:20,625
Donc, cette instruction si pour le commentaire n'est pas nulle.

742
01:00:20,625 --> 01:00:23,785
Donc, le reste si la partie,

743
01:00:23,785 --> 01:00:29,020
maintenant ce n'est pas applicable,

744
01:00:29,020 --> 01:00:33,325
donc nous allons dire autre, erreur.

745
01:00:33,325 --> 01:00:35,470
L' erreur dans ce cas.

746
01:00:35,470 --> 01:00:37,825
Donc, si le commentaire est nul,

747
01:00:37,825 --> 01:00:40,850
cela signifie que nous n'avons pas trouvé le commentaire là-dedans,

748
01:00:40,850 --> 01:00:43,650
donc vous ne pouvez pas modifier un commentaire inexistant.

749
01:00:43,650 --> 01:00:44,805
Donc, nous allons dire err,

750
01:00:44,805 --> 01:00:54,700
nouveau commentaire d'erreur req.params.commentID introuvable et ensuite nous allons retourner l'erreur.

751
01:00:54,700 --> 01:01:01,255
Donc, c'est ainsi que nous allons gérer la partie put de notre commentaire ici,

752
01:01:01,255 --> 01:01:04,099
puis enfin la suppression.

753
01:01:06,120 --> 01:01:11,130
Pour la suppression, encore une fois nous devrons d'abord trouver

754
01:01:11,130 --> 01:01:12,900
commentaires.findById (req.params.commentId)

755
01:01:12,900 --> 01:01:25,720
, puis commenter.

756
01:01:25,720 --> 01:01:28,150
Donc, nous allons chercher le commentaire.

757
01:01:28,150 --> 01:01:34,160
Donc, nous allons d'abord vérifier si le commentaire n'est pas égal à null.

758
01:01:36,180 --> 01:01:39,955
C' est important de vérifier ici.

759
01:01:39,955 --> 01:01:50,990
Ensuite, la partie suivante que nous vérifierons est si le comment.author est égal à req.user. _id.

760
01:01:58,830 --> 01:02:03,400
Nous nous assurons que cet utilisateur qui tente de supprimer

761
01:02:03,400 --> 01:02:08,060
ce commentaire est exactement le même utilisateur que celui qui a inséré le commentaire en premier lieu.

762
01:02:08,060 --> 01:02:10,750
Si ce n'est pas le cas,

763
01:02:10,750 --> 01:02:13,920
alors vous verrez « Vous n'êtes pas autorisé à supprimer ce commentaire ! »

764
01:02:13,920 --> 01:02:16,365
Et puis renvoyez le statut là-bas.

765
01:02:16,365 --> 01:02:20,920
Puis en bas ici,

766
01:02:20,920 --> 01:02:41,310
nous dirons commentaires.findbyidandRemove ici.

767
01:02:41,310 --> 01:02:48,750
Donc, nous dirons commentaires.findByidandRemove (req.params.commentID),

768
01:02:48,750 --> 01:02:54,035
alors nous obtiendrons une réponse du commentaire.

769
01:02:54,035 --> 01:02:55,630
Donc, à ce stade,

770
01:02:55,630 --> 01:02:59,830
nous allons simplement dire, RES.StatusCode.

771
01:02:59,830 --> 01:03:05,365
Donc, nous allons dire commentaires.findByIdAndRemove puis réponse.

772
01:03:05,365 --> 01:03:07,210
Si elle est correctement supprimée,

773
01:03:07,210 --> 01:03:10,915
nous dirons 200, puis la

774
01:03:10,915 --> 01:03:17,260
réponse res.json ici et nous allons également attraper l'erreur à ce stade.

775
01:03:17,260 --> 01:03:25,195
Donc, laissez-moi juste copier ça ici et ensuite nous inclurons la capture de l'erreur à ce stade.

776
01:03:25,195 --> 01:03:28,895
Donc, c'est la première chose qu'on vérifiera.

777
01:03:28,895 --> 01:03:33,500
Nous allons nous assurer que le commentaire n'est pas égal à null.

778
01:03:33,630 --> 01:03:38,360
Sinon, c'est donc l'autre partie.

779
01:03:39,810 --> 01:03:44,170
Donc, c'est la partie autre de l'erreur if else

780
01:03:44,170 --> 01:03:48,040
nouveau commentaire req.params.commentId pas trouvé et puis

781
01:03:48,040 --> 01:03:56,220
404 et envoyer la partie d'autre pour nous et puis la partie alors gérera de manière appropriée.

782
01:03:56,220 --> 01:04:01,460
Donc, ce sont les changements que nous faisons pour le routeur de commentaires ici.

783
01:04:01,460 --> 01:04:05,025
Donc, nous gérons le get put post and delete pour

784
01:04:05,025 --> 01:04:10,330
les commentaires barre oblique et les commentaires barre oblique barre oblique impact commentID.

785
01:04:10,330 --> 01:04:12,495
Donc, une fois que nous avons terminé cela,

786
01:04:12,495 --> 01:04:17,500
alors nous devons l'inclure dans le fichier app.js.

787
01:04:17,500 --> 01:04:27,345
Donc, nous allons aller dans le fichier app.js et puis nous dirons

788
01:04:27,345 --> 01:04:30,070
var commentrouter

789
01:04:31,130 --> 01:04:42,280
exiger routes/commentrouter.

790
01:04:42,280 --> 01:04:45,960
Donc, nous avons le routeur de commentaire ici et puis nous allons

791
01:04:45,960 --> 01:04:49,390
descendre dans le fichier app.js ci-dessous et

792
01:04:49,390 --> 01:04:54,610
ensuite nous dirons app.use

793
01:04:55,040 --> 01:05:04,695
commentaires slash, commentUter ici.

794
01:05:04,695 --> 01:05:07,365
C' est ça. Alors maintenant,

795
01:05:07,365 --> 01:05:09,390
mon routeur de commentaires est prêt.

796
01:05:09,390 --> 01:05:12,935
Alors, allons de l'avant et sauvegardons tous les changements.

797
01:05:12,935 --> 01:05:19,020
Ensuite, notre serveur est maintenant mis à jour

798
01:05:19,020 --> 01:05:24,420
afin de traiter toutes les demandes de nos clients React ici.

799
01:05:24,420 --> 01:05:27,800
Maintenant, si vous voulez faire l'alternative, c'est-à-dire que

800
01:05:27,800 --> 01:05:34,120
vous avez vos commentaires en tant que sous-documents de votre plat et que vous voulez gérer cela,

801
01:05:34,120 --> 01:05:37,680
alors vous devrez mettre à jour le client React pour

802
01:05:37,680 --> 01:05:42,185
pouvoir utiliser les commentaires de chaque plat de manière appropriée.

803
01:05:42,185 --> 01:05:44,830
Cela sera laissé comme un exercice pour vous.

804
01:05:44,830 --> 01:05:48,920
Pensez à la façon dont vous conceviez votre client de réaction de sorte qu'il

805
01:05:48,920 --> 01:05:53,465
fonctionne très bien avec

806
01:05:53,465 --> 01:06:03,735
la version antérieure du serveur qui avait les commentaires comme sous-documents de vos plats eux-mêmes.

807
01:06:03,735 --> 01:06:07,065
Maintenant, ce sera une façon intéressante de l'implémenter.

808
01:06:07,065 --> 01:06:10,480
Bien sûr, c'est un peu plus compliqué que la façon dont nous avons

809
01:06:10,480 --> 01:06:14,965
implémenté le client React où nous avons gardé

810
01:06:14,965 --> 01:06:20,840
les commentaires indépendants des plats, mais le travail supplémentaire est alors

811
01:06:20,840 --> 01:06:22,910
la responsabilité du côté client car vous devez sélectionner

812
01:06:22,910 --> 01:06:26,765
les commentaires appropriés lorsque vous affichez un plat spécifique.

813
01:06:26,765 --> 01:06:30,370
Vous devez sélectionner les commentaires de tous les commentaires ici.

814
01:06:30,370 --> 01:06:35,170
Donc, c'est un travail supplémentaire que notre client React fait en raison

815
01:06:35,170 --> 01:06:40,680
du fait que nous avons séparé les commentaires des plats eux-mêmes.

816
01:06:40,680 --> 01:06:46,165
De même, si vous pouvez reconcevoir votre client angulaire pour être en mesure de faire

817
01:06:46,165 --> 01:06:51,775
face à la situation où les commentaires sont conservés indépendamment de vos plats.

818
01:06:51,775 --> 01:06:56,020
Maintenant, donc ce sont tous des exercices que vous pouvez faire pour voir comment vous pouvez

819
01:06:56,020 --> 01:07:01,210
étendre vos applications clientes pour gérer n'importe quel type de serveur,

820
01:07:01,210 --> 01:07:04,430
les deux types différents de serveurs là-bas.

821
01:07:04,860 --> 01:07:11,480
Donc, avec cela, nous terminons la mise à jour de notre serveur ici.

822
01:07:11,480 --> 01:07:15,040
Donc, avec cela, nous avons tout mis à jour sur le côté serveur.

823
01:07:15,040 --> 01:07:17,890
Donc, sauvegardons toutes les modifications du côté serveur.

824
01:07:17,890 --> 01:07:26,755
Maintenant, notre serveur est prêt à traiter les demandes entrantes de notre client React.

825
01:07:26,755 --> 01:07:29,340
Avec cela, nous terminons cet exercice.

826
01:07:29,340 --> 01:07:33,300
Dans cet exercice, nous avons maintenant préparé notre serveur express

827
01:07:33,300 --> 01:07:38,985
pour traiter les demandes entrantes de notre client React.

828
01:07:38,985 --> 01:07:43,190
Dans le prochain exercice, nous allons examiner le client de réaction plus en détail pour

829
01:07:43,190 --> 01:07:48,000
comprendre comment il communique avec ce serveur supplémentaire.

830
01:07:48,000 --> 01:07:50,640
C' est le bon moment pour vous de faire

831
01:07:50,640 --> 01:07:55,880
une couverture git avec le message intégrant le client et le serveur.