1
00:00:03,650 --> 00:00:08,385
Avevamo già sviluppato un server API REST completo

2
00:00:08,385 --> 00:00:12,485
usando Express e MongoDB come parte di questo corso.

3
00:00:12,485 --> 00:00:16,965
Affinché quel server sia in grado di comunicare in modo significativo con il nostro cliente,

4
00:00:16,965 --> 00:00:19,590
faremo alcune piccole modifiche ad esso in

5
00:00:19,590 --> 00:00:22,440
modo che restituisca il giusto tipo di dati in modo che la

6
00:00:22,440 --> 00:00:24,780
nostra implementazione client possa funzionare

7
00:00:24,780 --> 00:00:28,935
in modo più efficiente con i dati restituiti dal nostro sito server.

8
00:00:28,935 --> 00:00:30,410
Quindi, per farlo,

9
00:00:30,410 --> 00:00:36,580
lavoriamo su alcune modifiche al nostro sito server in questo esercizio.

10
00:00:36,580 --> 00:00:39,215
Prima di iniziare questo esercizio,

11
00:00:39,215 --> 00:00:42,410
presumo che non hai fatto

12
00:00:42,410 --> 00:00:46,430
la lezione precedente sull'integrazione del client angolare e

13
00:00:46,430 --> 00:00:55,395
del server perché stai facendo questa lezione passando dalla specializzazione React.

14
00:00:55,395 --> 00:01:01,190
Quindi, le modifiche che apporterò al server assumeranno che

15
00:01:01,190 --> 00:01:07,430
la versione del server che stai modificando sia prima della lezione precedente.

16
00:01:07,430 --> 00:01:11,540
Nel caso in cui tu abbia fatto quella lezione sul client angolare,

17
00:01:11,540 --> 00:01:16,505
alcune delle modifiche apportate al tuo server verranno ripetute nuovamente

18
00:01:16,505 --> 00:01:22,495
in questo esercizio in modo da poter saltare quella parte delle modifiche.

19
00:01:22,495 --> 00:01:26,055
Entra nel nostro server nell'editor.

20
00:01:26,055 --> 00:01:29,125
Prima di iniziare a lavorare sul server,

21
00:01:29,125 --> 00:01:33,530
suggerirei di scaricare tutte le immagini che ho

22
00:01:33,530 --> 00:01:38,380
fornito come file zip nelle risorse di esercizio chiamate images.zip.

23
00:01:38,380 --> 00:01:43,160
Decomprimere il file e quindi ottenere tutte le immagini da lì e poi copiare quelle immagini

24
00:01:43,160 --> 00:01:48,290
nella cartella immagini pubbliche nel nostro server.

25
00:01:48,290 --> 00:01:55,010
Quindi, vedi che qui ho copiato tutte le immagini nella mia cartella di immagini pubbliche qui

26
00:01:55,010 --> 00:01:58,160
già perché il nostro server è quello che

27
00:01:58,160 --> 00:02:02,275
servirà tutte queste immagini per la nostra applicazione client.

28
00:02:02,275 --> 00:02:07,835
Successivamente, andiamo al CORS e aggiustiamo la whitelist qui.

29
00:02:07,835 --> 00:02:11,565
Quindi, per la nostra applicazione client React,

30
00:02:11,565 --> 00:02:15,275
se abbiamo iniziato con il comando di avvio del

31
00:02:15,275 --> 00:02:18,470
filato, viene eseguito al nome del computer: 3001.

32
00:02:18,470 --> 00:02:22,040
Quindi, qualsiasi richiesta proveniente dalla nostra posizione

33
00:02:22,040 --> 00:02:25,760
al server porterà quella come origine lì.

34
00:02:25,760 --> 00:02:30,380
Ecco perché ho intenzione di aggiungerlo nella mia whitelist in modo che

35
00:02:30,380 --> 00:02:35,390
tutti i problemi CORS vengano risolti automaticamente.

36
00:02:35,390 --> 00:02:40,985
Quindi, andando nel file cors.js nella mia whitelist qui,

37
00:02:40,985 --> 00:02:49,460
lasciami aggiungere il

38
00:02:49,460 --> 00:02:55,640
nome del computer http://my: 3001 e questa è

39
00:02:55,640 --> 00:02:58,610
l'origine da cui il mio client

40
00:02:58,610 --> 00:03:02,075
originerà le richieste che arrivano a questo server.

41
00:03:02,075 --> 00:03:07,075
Quindi, in questo modo il mio CORS non causerebbe problemi al mio cliente.

42
00:03:07,075 --> 00:03:11,690
Successivamente, abbiamo bisogno di aggiornare alcuni dei percorsi per

43
00:03:11,690 --> 00:03:17,690
gestire i parametri di query e anche alcuni piccoli altri aggiustamenti.

44
00:03:17,690 --> 00:03:21,280
Permettetemi di iniziare con il file promoRouter.js.

45
00:03:21,280 --> 00:03:25,010
Questo è semplice da aggiornare.

46
00:03:25,010 --> 00:03:27,570
Quindi, andando nel file promoRouter.js,

47
00:03:27,570 --> 00:03:32,360
nel file PromorOuter per la richiesta get che arriviamo

48
00:03:32,360 --> 00:03:37,610
qui invece di fare promozioni trovare con un oggetto JavaScript vuoto,

49
00:03:37,610 --> 00:03:47,320
qui vorrei fornire il req.query come parametro per le promozioni trovare qui,

50
00:03:47,320 --> 00:03:49,680
stessa cosa con il router leader anche.

51
00:03:49,680 --> 00:03:52,745
Quindi, lasciami andare al file leaderRouter.js.

52
00:03:52,745 --> 00:03:54,815
Nel router leader anche,

53
00:03:54,815 --> 00:04:00,545
qui dove trovi leaders.find con l'oggetto JavaScript vuoto invece

54
00:04:00,545 --> 00:04:06,685
sostituirlo con il req.query in modo che i parametri di query vengano passati.

55
00:04:06,685 --> 00:04:14,260
Quindi, questo è dove passeremo nella caratteristica: true come parametro di query qui.

56
00:04:14,260 --> 00:04:16,945
Ora, dopo aver regolato questi due,

57
00:04:16,945 --> 00:04:19,340
lavoriamo ora sul router piatto.

58
00:04:19,340 --> 00:04:22,115
Quindi, vai nel file dishRouter.js,

59
00:04:22,115 --> 00:04:26,310
anche nel router piatto anche lo stesso aggiornamento qui.

60
00:04:26,310 --> 00:04:31,200
Quindi, vai in questo piatti.Trova nel metodo get qui,

61
00:04:31,200 --> 00:04:33,945
cambialo in req.query.

62
00:04:33,945 --> 00:04:38,070
Quindi, con questo, il mio aggiornamento del router piatto è stato completato.

63
00:04:38,070 --> 00:04:42,085
Quindi, ora abbiamo aggiornato il router promozionale, il leader

64
00:04:42,085 --> 00:04:43,850
e il router piatto,

65
00:04:43,850 --> 00:04:48,050
quindi passeremo per aggiornare il router preferito.

66
00:04:48,050 --> 00:04:54,380
Ora, avresti implementato il router preferito come parte del tuo quarto incarico.

67
00:04:54,380 --> 00:04:56,530
Ora, nel router preferito,

68
00:04:56,530 --> 00:04:58,910
vedrai che per il router preferito,

69
00:04:58,910 --> 00:05:01,010
non ti sto mostrando la parte rimanente perché

70
00:05:01,010 --> 00:05:03,435
avresti dovuto fare come parte del tuo incarico.

71
00:05:03,435 --> 00:05:11,520
Innanzitutto, permettetemi di attirare la vostra attenzione sul metodo get per FavoriteRouter.Rout:dishID.

72
00:05:11,520 --> 00:05:17,405
Ora userò questo metodo get per verificare che

73
00:05:17,405 --> 00:05:25,460
il piatto specifico con il piatto Id sia già uno dei preferiti per l'utente.

74
00:05:25,460 --> 00:05:29,130
Quindi, invece di dire semplicemente getoperation.supported,

75
00:05:29,130 --> 00:05:36,165
sto solo andando a sfruttare la presenza di questa operazione get e poi diremo,

76
00:05:36,165 --> 00:05:47,500
favorites.Findone e diremo utente: req.user. _id.

77
00:05:49,220 --> 00:05:59,340
Quindi, troveremo i preferiti per quel particolare utente e poi diremo poi

78
00:06:03,070 --> 00:06:25,530
preferiti e cattura errore prossimo.

79
00:06:25,530 --> 00:06:35,265
Quindi allo stesso modo qui, aggiungeremo l'err qui, il prossimo err qui.

80
00:06:35,265 --> 00:06:37,380
Quindi, all'interno di questo allora,

81
00:06:37,380 --> 00:06:39,495
quando otteniamo i preferiti,

82
00:06:39,495 --> 00:06:45,360
allora controlleremo se non i preferiti.

83
00:06:45,360 --> 00:06:47,690
Quindi, se non ci sono preferiti per

84
00:06:47,690 --> 00:06:53,900
questo utente, ovviamente il piatto che stiamo controllando non esiste,

85
00:06:53,900 --> 00:07:07,520
quindi restituiremo 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 e poi torneremo dicendo esiste false.

88
00:07:36,735 --> 00:07:44,215
Quello che stiamo specificando qui è che se ottengono è fatto a questo punto finale con un Id piatto,

89
00:07:44,215 --> 00:07:52,835
questa bandiera esiste qui sarà impostata su true se questo piatto fa parte dei miei preferiti.

90
00:07:52,835 --> 00:07:55,290
Se questo piatto non fa parte dei miei preferiti,

91
00:07:55,290 --> 00:07:58,100
Io impostare là esiste bandiera su false.

92
00:07:58,100 --> 00:08:01,190
Quindi qui, vedi che dal momento che non ho alcun favorito, quindi

93
00:08:01,190 --> 00:08:04,770
esiste dovrebbe essere automaticamente falso a questo punto.

94
00:08:04,770 --> 00:08:13,020
Quindi, diremo esiste falso e poi restituiremo i preferiti qui.

95
00:08:13,180 --> 00:08:19,090
Beh, ovviamente, in questo caso i favoriti sarebbero nulli a questo punto.

96
00:08:19,090 --> 00:08:26,440
Altrimenti, il che significa che i preferiti non è nullo,

97
00:08:26,440 --> 00:08:32,750
quindi diremo se favorites.dishes.indexOf.

98
00:08:36,840 --> 00:08:45,995
Quindi, stiamo andando a cercare Req.params.dishID.

99
00:08:45,995 --> 00:08:51,220
Quindi, stiamo andando a cercare questo array piatti preferiti per

100
00:08:51,220 --> 00:08:56,605
vedere se questo piatto esiste lì e se non esiste,

101
00:08:56,605 --> 00:09:00,525
ovviamente questo restituirà un indice negativo qui.

102
00:09:00,525 --> 00:09:02,340
Anche in questo caso,

103
00:09:02,340 --> 00:09:05,440
restituirò esattamente lo stesso di qui.

104
00:09:05,440 --> 00:09:08,630
Quindi, se restituisce un indice negativo significa che anche

105
00:09:08,630 --> 00:09:12,260
se questo particolare utente ha un insieme di preferiti,

106
00:09:12,260 --> 00:09:16,190
questo piatto specifico non esiste

107
00:09:16,190 --> 00:09:22,340
nella lista dei suoi preferiti, quindi è per questo che restituirà esiste falso qui.

108
00:09:22,340 --> 00:09:30,255
Ora, altrimenti ciò significa che il piatto esiste nella lista dei preferiti.

109
00:09:30,255 --> 00:09:31,859
Quindi, in questo caso,

110
00:09:31,859 --> 00:09:36,670
restituirò il codice di stato 200 esiste è vero.

111
00:09:36,670 --> 00:09:43,825
In questo modo, quando l'utente esegue un'operazione get su questo endpoint con

112
00:09:43,825 --> 00:09:52,015
il/favorites/dishId dove viene fornito l'Id piatto

113
00:09:52,015 --> 00:09:55,630
come parametro qui, come parametro di richiesta qui,

114
00:09:55,630 --> 00:10:00,650
allora controlleremo per vedere se quel piatto esiste nei preferiti.

115
00:10:00,650 --> 00:10:05,775
Se nessuno dei preferiti esiste per questo utente, allora restituiremo un falso esiste.

116
00:10:05,775 --> 00:10:08,120
Allo stesso modo, se i preferiti esiste ma

117
00:10:08,120 --> 00:10:12,320
quel piatto particolare non esiste nei preferiti allora restituiremo false,

118
00:10:12,320 --> 00:10:13,910
altrimenti restituiremo true.

119
00:10:13,910 --> 00:10:20,260
Quindi questa bandiera esiste può essere utilizzata dal mio cliente per verificare se questo piatto fa

120
00:10:20,260 --> 00:10:27,755
parte della lista dei piatti preferiti per questo utente o meno.

121
00:10:27,755 --> 00:10:30,139
Anche mentre siamo in preferiti,

122
00:10:30,139 --> 00:10:33,410
ogni volta che apportiamo modifiche ai preferiti,

123
00:10:33,410 --> 00:10:37,870
vogliamo essere in grado di popolare le informazioni utente e piatti,

124
00:10:37,870 --> 00:10:39,535
i preferiti, prima di tornare.

125
00:10:39,535 --> 00:10:43,240
Ad esempio, nel post che facciamo,

126
00:10:43,240 --> 00:10:48,470
quando salviamo i preferiti allora a questo punto,

127
00:10:48,470 --> 00:10:55,470
vorremmo prima fare i preferiti.

128
00:10:55,620 --> 00:11:06,380
FindById, quindi perché abbiamo appena apportato le modifiche diremo favorite_id

129
00:11:07,740 --> 00:11:15,325
e popoleremo sia l'utente che anche

130
00:11:15,325 --> 00:11:25,490
i piatti nei preferiti.

131
00:11:25,740 --> 00:11:32,420
Poi, quando i preferiti vengono restituiti,

132
00:11:32,610 --> 00:11:36,940
restituiremo quei preferiti invece.

133
00:11:36,940 --> 00:11:40,440
Quindi, lasciatemi fare questo cambiamento qui.

134
00:11:40,440 --> 00:11:46,910
Quindi, taglieremo questo fuori da qui e poi all'interno del poi,

135
00:11:46,910 --> 00:11:49,645
restituiremo i preferiti.

136
00:11:49,645 --> 00:11:53,510
Dopo aver salvato i preferiti,

137
00:11:53,510 --> 00:11:54,980
allora cercheremo per esso,

138
00:11:54,980 --> 00:11:58,285
per il FavoriteById e poi restituire

139
00:11:58,285 --> 00:12:03,940
quel preferito qui così diremo poi ritorno preferito e codice di stato.

140
00:12:03,940 --> 00:12:05,355
Questo cambiamento che dovremmo fare.

141
00:12:05,355 --> 00:12:08,180
Se lo hai già implementato nei tuoi preferiti

142
00:12:08,180 --> 00:12:09,760
, non è necessario apportare questa modifica.

143
00:12:09,760 --> 00:12:13,310
Ma quello che stiamo facendo è ogni volta che apportiamo modifiche ai preferiti,

144
00:12:13,310 --> 00:12:17,380
popoleremo sia le informazioni utente che i piatti e quindi restituiremo questo valore

145
00:12:17,380 --> 00:12:22,360
perché il nostro client React si aspetta che questo sia lì.

146
00:12:22,360 --> 00:12:24,685
Ora, lo stesso tipo di cambiamento,

147
00:12:24,685 --> 00:12:28,350
avremo bisogno di fare la variabile b, salvare le modifiche.

148
00:12:28,350 --> 00:12:33,125
Quindi nel post qui,

149
00:12:33,125 --> 00:12:36,090
faremo una modifica a questo,

150
00:12:36,090 --> 00:12:42,705
quindi diremo favorites.save e poi faremo favorites.FindById e fare quel cambiamento.

151
00:12:42,705 --> 00:12:45,210
Allo stesso modo, sotto l'id

152
00:12:45,210 --> 00:12:47,095
del piatto, anche nel post,

153
00:12:47,095 --> 00:12:51,070
sarai allo stesso modo, ogni volta che

154
00:12:51,070 --> 00:12:57,715
apporterai modifiche ai preferiti, lo cercherai prima e poi popolerai sia l'utente che i piatti e poi lo restituirai,

155
00:12:57,715 --> 00:12:59,910
e poi similmente nella parte else.

156
00:12:59,910 --> 00:13:06,290
Quindi, devi averlo implementato nel tuo quarto incarico.

157
00:13:06,290 --> 00:13:09,010
Quindi, apporta questa modifica aggiuntiva in cui popolerai

158
00:13:09,010 --> 00:13:12,350
l'utente e i piatti prima di restituire il valore.

159
00:13:12,350 --> 00:13:14,685
Anche con l'eliminazione,

160
00:13:14,685 --> 00:13:17,385
faremo le stesse modifiche qui.

161
00:13:17,385 --> 00:13:19,890
Quindi, noti che nella cancellazione,

162
00:13:19,890 --> 00:13:21,830
ho già fatto questo cambiamento qui.

163
00:13:21,830 --> 00:13:27,085
Quindi, dopo aver salvato le modifiche ai preferiti,

164
00:13:27,085 --> 00:13:29,480
cercheremo i preferiti e

165
00:13:29,480 --> 00:13:33,465
torneremo dopo aver popolato sia l'utente che i piatti e i preferiti.

166
00:13:33,465 --> 00:13:36,505
Questo è ciò che il nostro cliente React si aspetta da noi.

167
00:13:36,505 --> 00:13:38,145
Quindi, anche per l'eliminazione,

168
00:13:38,145 --> 00:13:39,995
faremo le stesse modifiche.

169
00:13:39,995 --> 00:13:44,115
Ora, con questo, il mio router preferito viene aggiornato,

170
00:13:44,115 --> 00:13:48,575
quindi procederemo avanti all'aggiornamento di users.js successivo.

171
00:13:48,575 --> 00:13:52,370
Infine, aggiorneremo il file users.js.

172
00:13:52,370 --> 00:13:57,060
Ora, nel file users.js dobbiamo aggiungere

173
00:13:57,060 --> 00:14:05,245
un altro campo router.options qui,

174
00:14:05,245 --> 00:14:10,610
perché a volte una richiesta di post come hai visto

175
00:14:10,610 --> 00:14:16,315
con il login invierà prima le opzioni per verificare,

176
00:14:16,315 --> 00:14:21,610
specialmente con le auto, se la richiesta di post sarà consentita.

177
00:14:21,610 --> 00:14:30,080
Ecco perché controlleremo il corso con le opzioni qui e poi

178
00:14:31,860 --> 00:14:35,450
restituiremo semplicemente

179
00:14:39,960 --> 00:14:43,045
un messaggio

180
00:14:43,045 --> 00:14:46,180
di stato di 200 in risposta a questo.

181
00:14:46,180 --> 00:14:52,960
Per qualsiasi endpoint sotto gli utenti se riceviamo le opzioni,

182
00:14:52,960 --> 00:14:56,530
restituiremo semplicemente uno stato 200 qui.

183
00:14:56,530 --> 00:15:03,580
Ora la funzione di login che avevamo implementato in precedenza,

184
00:15:03,580 --> 00:15:07,470
avevamo semplicemente fatto passport.authenticate

185
00:15:07,470 --> 00:15:12,930
locale qui e abbiamo controllato i valori rimanenti qui.

186
00:15:12,930 --> 00:15:15,215
Ora, questo passport.authenticate locale,

187
00:15:15,215 --> 00:15:17,600
se l'utente non viene autenticato,

188
00:15:17,600 --> 00:15:21,800
restituisce semplicemente un non autorizzato nel messaggio di risposta.

189
00:15:21,800 --> 00:15:28,380
Ora questo potrebbe non essere molto significativo per il lato client per visualizzare queste informazioni,

190
00:15:28,380 --> 00:15:30,480
quindi è per questo che miglioreremo

191
00:15:30,480 --> 00:15:36,310
questo metodo di login post router in modo

192
00:15:36,310 --> 00:15:41,765
tale che l'autenticazione restituirà informazioni più significative a questo punto.

193
00:15:41,765 --> 00:15:43,210
Quindi, per farlo,

194
00:15:43,210 --> 00:15:49,395
non stiamo andando a fare il passport.authenticate qui,

195
00:15:49,395 --> 00:15:51,955
invece ci prenderemo.

196
00:15:51,955 --> 00:15:55,140
Quindi, lasciami rimuovere da lì e poi vedrai

197
00:15:55,140 --> 00:15:58,930
come aggiornerò il post del router qui.

198
00:15:58,930 --> 00:16:08,620
Quindi, vedremo corso con le opzioni e poi includeremo il req,

199
00:16:08,620 --> 00:16:12,160
res e il prossimo qui.

200
00:16:12,160 --> 00:16:16,885
All' interno di questo req, res e il prossimo qui,

201
00:16:16,885 --> 00:16:27,954
passport.authenticate chiamerà questo con local.

202
00:16:27,954 --> 00:16:31,210
Ora, quando chiamiamo questo con locale,

203
00:16:31,210 --> 00:16:34,970
se si verifica un errore di autenticazione,

204
00:16:34,970 --> 00:16:38,240
il passport.authenticate può essere fatto per restituire

205
00:16:38,240 --> 00:16:44,230
il valore di errore e inoltre restituirà l'utente se

206
00:16:44,230 --> 00:16:48,960
non ci sono errori e un terzo parametro chiamato info

207
00:16:48,960 --> 00:16:54,000
che porterà informazioni aggiuntive che potrebbero essere analizzate di nuovo a l'utente.

208
00:16:54,000 --> 00:16:56,580
Questo errore verrà restituito quando si

209
00:16:56,580 --> 00:16:59,950
verifica un errore autentico nel passport.authenticate.

210
00:16:59,950 --> 00:17:03,400
Ma se le informazioni dell'utente

211
00:17:03,400 --> 00:17:07,645
vengono inviate in passport.authenticate ma l'utente non esiste,

212
00:17:07,645 --> 00:17:10,490
allora ciò non viene conteggiato come un errore.

213
00:17:10,490 --> 00:17:14,690
Invece, verrà conteggiato come utente non esiste e

214
00:17:14,690 --> 00:17:19,305
che le informazioni vengono analizzate nuovamente nell'oggetto info che entra in.

215
00:17:19,305 --> 00:17:21,500
Pertanto, l'errore verrà restituito quando si

216
00:17:21,500 --> 00:17:24,925
verifica un errore genuino durante il processo di autenticazione,

217
00:17:24,925 --> 00:17:30,820
ma le informazioni conterranno informazioni se l'utente non esiste.

218
00:17:30,820 --> 00:17:36,920
Quindi, il passport.authenticate sta restituendo un messaggio che dice che

219
00:17:36,920 --> 00:17:39,575
l'utente non esiste o che il nome utente non

220
00:17:39,575 --> 00:17:42,850
è corretto o che la password non è corretta e così via.

221
00:17:42,850 --> 00:17:46,870
Quindi, tali informazioni verranno passate nel messaggio info.

222
00:17:46,870 --> 00:17:49,230
Ora vedremo come questo

223
00:17:49,230 --> 00:17:52,060
ci è utile quando guardiamo il lato client un po 'più tardi.

224
00:17:52,060 --> 00:17:55,400
Quindi, in questa situazione,

225
00:17:55,400 --> 00:18:01,455
gestiremo questo come segue,

226
00:18:01,455 --> 00:18:06,810
e non solo quando chiamiamo questo passport.authenticate,

227
00:18:06,810 --> 00:18:10,220
abbiamo anche bisogno di passare in un req,

228
00:18:10,220 --> 00:18:15,080
res, accanto come i tre parametri ad esso.

229
00:18:15,080 --> 00:18:20,130
Quindi, questa è la struttura quando devi chiamare passport.authenticate e aspettarti che

230
00:18:20,130 --> 00:18:25,270
ti trasmetta informazioni come questo come metodo di callback qui,

231
00:18:25,270 --> 00:18:27,630
quindi devi anche fornire questo req, res,

232
00:18:27,630 --> 00:18:30,250
anche lì.

233
00:18:30,250 --> 00:18:32,270
Ora, se questo si verifica,

234
00:18:32,270 --> 00:18:36,780
quindi diremo se err,

235
00:18:36,780 --> 00:18:40,425
quindi se c'è un errore che si verifica,

236
00:18:40,425 --> 00:18:45,395
diremo restituire il prossimo

237
00:18:45,395 --> 00:18:51,480
errore e poi lasciare che il gestore degli errori del nostro router espresso e prendersi cura di questo.

238
00:18:51,480 --> 00:18:56,755
Ora, prenderemo in considerazione altre situazioni, se non utente.

239
00:18:56,755 --> 00:18:59,630
Quindi, se abbiamo raggiunto questo punto,

240
00:18:59,630 --> 00:19:02,580
significa che non è stato un errore che si è verificato,

241
00:19:02,580 --> 00:19:05,615
ma invece forse l'utente non è stato trovato.

242
00:19:05,615 --> 00:19:07,100
Se l'utente non viene trovato,

243
00:19:07,100 --> 00:19:11,190
l'utente qui verrà impostato su null in questo caso.

244
00:19:11,190 --> 00:19:14,634
Quindi, in questa situazione,

245
00:19:14,634 --> 00:19:17,375
se l'utente non esiste,

246
00:19:17,375 --> 00:19:23,680
allora dobbiamo essere in grado di passare le informazioni sul lato server.

247
00:19:23,680 --> 00:19:28,435
Quindi, quello che faremo è passeremo in queste informazioni in questo formato.

248
00:19:28,435 --> 00:19:32,020
Quindi, ho intenzione di tagliare questo fuori da qui e

249
00:19:32,020 --> 00:19:36,640
poi incollarlo qui e poi lo modificheremo.

250
00:19:36,640 --> 00:19:40,704
Quindi, se l'utente è nullo,

251
00:19:40,704 --> 00:19:45,830
allora invieremo un codice di stato come 401 che significa

252
00:19:45,830 --> 00:19:53,975
non autorizzato e poi invieremo informazioni di successo false,

253
00:19:53,975 --> 00:19:57,405
e quindi non passeremo indietro il token,

254
00:19:57,405 --> 00:20:00,795
passeremo indietro il messaggio di stato.

255
00:20:00,795 --> 00:20:03,135
Quindi, qui diremo

256
00:20:03,135 --> 00:20:12,670
'Login Unsuccessfu' e poi la terza informazione,

257
00:20:12,670 --> 00:20:18,070
passeremo queste informazioni quell'oggetto che abbiamo ricevuto qui come

258
00:20:18,070 --> 00:20:25,635
la terza parte nel messaggio di risposta che inviamo indietro dal nostro server qui.

259
00:20:25,635 --> 00:20:28,935
Quindi, il flag di successo verrà impostato su false,

260
00:20:28,935 --> 00:20:32,385
lo stato verrà impostato Login non riuscito e

261
00:20:32,385 --> 00:20:36,725
le informazioni di errore passate nelle informazioni verranno restituite.

262
00:20:36,725 --> 00:20:39,855
Ora, si noti che questa situazione si verificherà se

263
00:20:39,855 --> 00:20:43,125
il nome utente e la password non sono corretti,

264
00:20:43,125 --> 00:20:48,600
e quindi questo non è un errore nel senso di errore, ma

265
00:20:48,600 --> 00:20:54,040
il fatto che l'autenticazione non è riuscito a trovare l'utente o la password dell'utente non è corretto.

266
00:20:54,040 --> 00:20:58,530
Quindi, tali informazioni saranno codificate nelle informazioni che entrano e in modo che io

267
00:20:58,530 --> 00:21:04,590
possa tornare come errore al mio lato client.

268
00:21:04,590 --> 00:21:09,615
La parte altrimenti

269
00:21:09,615 --> 00:21:15,355
viene gestita come REQ.login.

270
00:21:15,355 --> 00:21:17,220
Quindi, se questo ha successo,

271
00:21:17,220 --> 00:21:22,710
il passport.authenticate aggiungeremo questo metodo chiamato REQ.Login all'utente.

272
00:21:22,710 --> 00:21:24,340
Quindi, a questo punto,

273
00:21:24,340 --> 00:21:27,950
passeremo semplicemente l'oggetto utente che abbiamo ottenuto.

274
00:21:27,950 --> 00:21:31,055
Quindi qui, se abbiamo raggiunto questo punto,

275
00:21:31,055 --> 00:21:36,195
allora ciò significa che l'oggetto utente non è nullo e anche nessun errore si è verificato,

276
00:21:36,195 --> 00:21:40,090
quindi ciò significa che l'utente può essere loggato.

277
00:21:41,080 --> 00:21:44,550
Quindi, diremo err,

278
00:21:48,960 --> 00:21:51,460
proveremo ad accedere all'utente.

279
00:21:51,460 --> 00:21:58,000
Quindi, diremo se err e

280
00:21:58,000 --> 00:22:05,345
poi passeremo indietro lo stesso tipo di informazioni di errore che abbiamo fatto qui.

281
00:22:05,345 --> 00:22:09,840
Quindi, in questo caso, se l'errore,

282
00:22:13,290 --> 00:22:19,430
poi passeremo indietro un codice di stato come 401 e diremo che il successo

283
00:22:19,430 --> 00:22:25,125
è falso e lo stato come Login UnSuccess

284
00:22:25,125 --> 00:22:28,340
, e quindi le informazioni

285
00:22:29,280 --> 00:22:31,840
di errore, invece delle informazioni,

286
00:22:31,840 --> 00:22:42,380
passeremo in 'Impossibile accedere utente».

287
00:22:42,380 --> 00:22:48,960
Quindi, questo è il messaggio che passeremo qui se si verifica l'errore.

288
00:22:48,960 --> 00:22:53,200
Altrimenti, saremmo qui sotto.

289
00:22:53,200 --> 00:22:55,960
Quindi, a questo punto,

290
00:22:55,960 --> 00:22:59,440
saremmo in grado di generare il token.

291
00:22:59,440 --> 00:23:02,495
Quindi, se abbiamo raggiunto fino a questo punto, ciò

292
00:23:02,495 --> 00:23:06,370
significa che l'utente ha effettuato correttamente l'accesso,

293
00:23:06,370 --> 00:23:08,430
e quindi ora possiamo generare il token.

294
00:23:08,430 --> 00:23:12,705
Quindi, genereremo il token in base all'ID dell'utente,

295
00:23:12,705 --> 00:23:18,350
e poi passeremo indietro il token all'utente.

296
00:23:18,350 --> 00:23:21,635
Quindi, qui, diremo token var,

297
00:23:21,635 --> 00:23:30,730
e quindi possiamo dire res.statusCode è 200 e quindi res.json successo vero,

298
00:23:30,730 --> 00:23:33,600
quindi, il che significa che l'utente ha effettuato correttamente l'accesso.

299
00:23:33,600 --> 00:23:38,490
Quindi, lo stato sarebbe login riuscito.

300
00:23:38,490 --> 00:23:40,605
Quindi, la terza parte,

301
00:23:40,605 --> 00:23:42,360
invece dell'errore,

302
00:23:42,360 --> 00:23:46,200
passerò il token all'utente.

303
00:23:46,200 --> 00:23:48,760
Quindi, diremo token,

304
00:23:51,100 --> 00:23:54,675
questo token che abbiamo appena ottenuto in precedenza.

305
00:23:54,675 --> 00:24:01,030
Quindi, quel token verrà passato come proprietà token del messaggio di risposta.

306
00:24:01,030 --> 00:24:04,560
Quindi, qui, si noti che il successo è impostato su true, quindi, il

307
00:24:04,560 --> 00:24:08,340
che significa che l'utente ha effettuato correttamente l'accesso,

308
00:24:08,340 --> 00:24:12,290
e quindi l'utente può procedere ulteriormente a questo punto.

309
00:24:12,290 --> 00:24:19,050
Questo deve essere fatto all'interno di REQ.login qui.

310
00:24:19,820 --> 00:24:22,970
Quindi, a questo punto,

311
00:24:22,970 --> 00:24:27,180
chiuderemo il REQ.login.

312
00:24:27,180 --> 00:24:33,735
Quindi, nota che questo è all'interno di questo REQ.login qui.

313
00:24:33,735 --> 00:24:37,320
Quindi, li' dentro, passeremo questi tre indietro.

314
00:24:37,320 --> 00:24:41,370
Quindi, lasciatemi solo rientrare queste tre righe in.

315
00:24:41,720 --> 00:24:48,850
Quindi, questo è il modo in cui gestiremmo il metodo di registrazione dell'utente.

316
00:24:48,850 --> 00:24:52,230
Quindi, di nuovo, rivedere questo codice ancora una volta.

317
00:24:52,230 --> 00:24:53,950
Quindi, faremo post router,

318
00:24:53,950 --> 00:24:56,815
ma invece di fare l'autenticazione passaporto proprio lì,

319
00:24:56,815 --> 00:24:58,960
diremo req, res,

320
00:24:58,960 --> 00:25:01,240
prossimo, e poi dentro qui,

321
00:25:01,240 --> 00:25:04,285
faremo un passaporto autenticato per il locale,

322
00:25:04,285 --> 00:25:06,560
e questo autenticato passerà indietro.

323
00:25:06,560 --> 00:25:09,250
Quindi, possiamo fornire una funzione di callback a questo,

324
00:25:09,250 --> 00:25:11,810
e questa funzione di callback restituirà l'errore,

325
00:25:11,810 --> 00:25:14,730
l'utente o le informazioni qui.

326
00:25:14,730 --> 00:25:16,300
Quindi, se si tratta di un errore,

327
00:25:16,300 --> 00:25:20,735
permetteremo solo al gestore di errori espresso di occuparsi di questo.

328
00:25:20,735 --> 00:25:22,730
Se l'utente è nullo

329
00:25:22,730 --> 00:25:26,940
, significa che l'accesso dell'utente non ha avuto successo

330
00:25:26,940 --> 00:25:29,730
e il motivo sarà nelle informazioni.

331
00:25:29,730 --> 00:25:36,870
Quindi, questo passerà come errore di informazioni nel messaggio di risposta qui.

332
00:25:36,870 --> 00:25:38,790
Se arriviamo a questo punto,

333
00:25:38,790 --> 00:25:43,555
l'utente viene verificato con successo.

334
00:25:43,555 --> 00:25:45,400
Quindi, allora effettueremo il login all'utente.

335
00:25:45,400 --> 00:25:47,630
Quindi, il passaporto si autentica,

336
00:25:47,630 --> 00:25:53,385
aggiungeremo in questo metodo chiamato login al req, il messaggio di richiesta.

337
00:25:53,385 --> 00:25:56,770
Quindi, possiamo chiamare il login con l'utente.

338
00:25:56,770 --> 00:25:59,355
Se questo restituisce un errore,

339
00:25:59,355 --> 00:26:03,105
allora restituiremo l'errore qui in modo appropriato.

340
00:26:03,105 --> 00:26:08,590
In caso contrario, avremo raggiunto il punto in cui l'utente è autenticato con successo.

341
00:26:08,590 --> 00:26:12,630
Quindi, siamo in grado di generare il token Web JSON qui e quindi restituire

342
00:26:12,630 --> 00:26:18,315
il token Web JSON all'utente per confermare che l'utente è connesso correttamente.

343
00:26:18,315 --> 00:26:21,545
Quindi, questo è l'insieme di passi che useremo qui.

344
00:26:21,545 --> 00:26:25,735
Ora, il motivo per cui faccio un modo più elaborato di gestirlo è che

345
00:26:25,735 --> 00:26:30,035
voglio distinguere tra la situazione in cui

346
00:26:30,035 --> 00:26:34,170
si verifica un errore genuino durante il processo di autenticazione rispetto alla situazione

347
00:26:34,170 --> 00:26:39,095
in cui il nome utente non è valido o la password non è valida.

348
00:26:39,095 --> 00:26:42,860
Quindi, questi due casi saranno gestiti da questa situazione,

349
00:26:42,860 --> 00:26:46,550
dove le informazioni porteranno le informazioni a noi.

350
00:26:46,550 --> 00:26:48,900
Quindi, questo non è un errore di per sé,

351
00:26:48,900 --> 00:26:52,090
ma questa è una situazione in cui l'utente

352
00:26:52,090 --> 00:26:55,710
non è un utente valido o la password dell'utente non è valida.

353
00:26:55,710 --> 00:27:01,070
Quindi, è così che gestiremo il processo di accesso dell'utente.

354
00:27:01,070 --> 00:27:03,660
Inoltre, aggiungerò

355
00:27:03,660 --> 00:27:14,825
un altro metodo qui chiamato checkJwttoken.

356
00:27:14,825 --> 00:27:21,100
È del tutto possibile che, mentre il client ha effettuato l'accesso e ottenere il token Web JSON,

357
00:27:21,100 --> 00:27:24,855
in un secondo momento, il token Web JSON potrebbe scadere.

358
00:27:24,855 --> 00:27:32,840
Pertanto, se l'utente tenta di accedere dal lato client con un token scaduto al server,

359
00:27:32,840 --> 00:27:35,610
il server non sarà in grado di autenticare l'utente.

360
00:27:35,610 --> 00:27:37,780
Quindi, a intervalli periodici,

361
00:27:37,780 --> 00:27:42,180
potremmo desiderare di effettuare un controllo incrociato per assicurarci che il token Web JSON sia ancora valido.

362
00:27:42,180 --> 00:27:44,975
Quindi, questo è il motivo per cui sto includendo questo,

363
00:27:44,975 --> 00:27:49,620
un altro endpoint chiamato CheckJWttoken.

364
00:27:49,620 --> 00:27:53,155
Quindi, se si esegue un get al checkJWtToken

365
00:27:53,155 --> 00:27:58,700
includendo il token nell'intestazione di autorizzazione,

366
00:27:58,700 --> 00:28:02,490
questa chiamata restituirà un true o false

367
00:28:02,490 --> 00:28:06,535
per indicare se il token Web JSON è ancora valido o meno.

368
00:28:06,535 --> 00:28:10,930
Se non è valido, il lato client può avviare un altro accesso per

369
00:28:10,930 --> 00:28:15,945
l'utente per ottenere un nuovo token Web JSON, se necessario.

370
00:28:15,945 --> 00:28:17,285
Quindi, per fare questo,

371
00:28:17,285 --> 00:28:27,109
diremo cors.corsWithOptions e req,

372
00:28:27,109 --> 00:28:31,385
res qui come previsto.

373
00:28:31,385 --> 00:28:35,670
Qui, diremo

374
00:28:39,820 --> 00:28:49,360
passaporto autenticare jwt

375
00:28:49,360 --> 00:28:57,150
e sessione: false,

376
00:29:00,020 --> 00:29:07,270
e questo restituirebbe err, utente, informazioni.

377
00:29:09,020 --> 00:29:13,770
Quindi, ricorda come usiamo il passaporto autenticare in precedenza.

378
00:29:13,770 --> 00:29:17,195
Quindi, chiamiamo il JWT con sessione false qui.

379
00:29:17,195 --> 00:29:21,745
Quindi, prima qui, diciamo che il passaporto autentichi il locale.

380
00:29:21,745 --> 00:29:23,535
Quindi, questo è per l'autenticazione locale.

381
00:29:23,535 --> 00:29:27,330
Quindi, questo è per l'autenticazione JSON Web Token.

382
00:29:27,330 --> 00:29:29,430
Quindi, quando lo chiamiamo,

383
00:29:29,430 --> 00:29:33,435
allora dal momento che questo sta per verificare il token Web JSON, quindi diremo,

384
00:29:33,435 --> 00:29:40,335
se err restituisce il prossimo

385
00:29:40,335 --> 00:29:44,895
errore, e quindi lasciare che il gestore di errori espresso si occupi di quella situazione.

386
00:29:44,895 --> 00:29:50,469
Quindi, diremo, se non utente,

387
00:29:53,330 --> 00:30:00,330
se l'utente non esiste, quindi allo stesso modo.

388
00:30:00,330 --> 00:30:03,510
Quindi, il che significa che se l'oggetto utente è stato

389
00:30:03,510 --> 00:30:07,810
trovato dal token Web JSON e quindi caricato su req.user,

390
00:30:07,810 --> 00:30:11,400
significa che l'utente è un utente valido

391
00:30:11,400 --> 00:30:13,485
e quindi può essere autorizzato a procedere ulteriormente.

392
00:30:13,485 --> 00:30:20,330
Altrimenti, diremo che l'utente non esiste.

393
00:30:20,330 --> 00:30:24,995
Quindi, dobbiamo informare che il token Web JSON è scaduto.

394
00:30:24,995 --> 00:30:26,180
Quindi, a questo punto,

395
00:30:26,180 --> 00:30:29,090
invieremo una riserva con

396
00:30:29,090 --> 00:30:36,545
un codice di stato di 401.

397
00:30:36,545 --> 00:30:47,130
Quindi, non autorizzato, SetHeader, Content-Type,

398
00:30:49,900 --> 00:30:56,280
application/json, e quindi restituiremo res.

399
00:30:58,680 --> 00:31:13,750
Res.json dirà lo stato JWT

400
00:31:13,750 --> 00:31:17,090
non valido e quindi,

401
00:31:17,730 --> 00:31:23,690
restituiremo un flag chiamato cade successo e poi,

402
00:31:23,880 --> 00:31:29,080
restituiremo le informazioni che otteniamo se l'utente

403
00:31:29,080 --> 00:31:34,460
non è autenticato come l'errore a questo punto.

404
00:31:36,420 --> 00:31:40,480
Altrimenti, ciò significa che abbiamo raggiunto questo punto,

405
00:31:40,480 --> 00:31:43,220
quindi l'utente è un utente valido.

406
00:31:43,220 --> 00:31:44,850
Quindi, in questo caso,

407
00:31:44,850 --> 00:31:47,230
fammi solo copiare quel codice qui,

408
00:31:47,230 --> 00:31:54,070
invieremo un codice di stato di 200 e quindi il res.json,

409
00:31:54,070 --> 00:32:02,720
invierà JWT valido e di successo essendo vero.

410
00:32:02,940 --> 00:32:09,820
La terza parte, invieremo le informazioni dell'utente. In

411
00:32:09,820 --> 00:32:16,000
questo modo, quando questo endpoint viene chiamato con il metodo get,

412
00:32:16,000 --> 00:32:19,170
questo verificherà se il token è valido o meno.

413
00:32:19,170 --> 00:32:20,220
Se il token è valido,

414
00:32:20,220 --> 00:32:24,020
riceverai questa risposta e dal flag di successo nella risposta,

415
00:32:24,020 --> 00:32:27,770
puoi verificare se il jsonwebtoken è valido o meno.

416
00:32:27,770 --> 00:32:32,155
Questo è utile sul lato client.

417
00:32:32,155 --> 00:32:37,825
Ora, questo passaporto autenticato qui dovrà essere fornito

418
00:32:37,825 --> 00:32:43,790
con req e res come i due parametri qui.

419
00:32:43,790 --> 00:32:47,630
Quindi, è così che chiamiamo l'autenticazione del passaporto.

420
00:32:47,630 --> 00:32:49,355
Quindi, si noti che ogni volta che si chiama

421
00:32:49,355 --> 00:32:52,840
passaporto autenticazione e si aspetta questa funzione di callback qui,

422
00:32:52,840 --> 00:33:01,825
è necessario aggiungere a questo punto req.res al passaporto autenticato sul retro qui.

423
00:33:01,825 --> 00:33:03,890
Nel nostro server API di riposo,

424
00:33:03,890 --> 00:33:07,490
avevamo implementato i nostri commenti in modo tale che i commenti

425
00:33:07,490 --> 00:33:12,245
formavano sotto-documenti all'interno del documento di dishe, in

426
00:33:12,245 --> 00:33:16,540
modo che comprassero ogni piatto racchiuse la propria serie di commenti.

427
00:33:16,540 --> 00:33:19,520
Ma il modo in cui abbiamo implementato il nostro cliente React è

428
00:33:19,520 --> 00:33:22,965
tale che i commenti sono tenuti indipendenti dai piatti,

429
00:33:22,965 --> 00:33:27,680
e i commenti stessi portavano l'ID piatto corrispondente.

430
00:33:27,680 --> 00:33:30,400
Ora, questi sono due modi diversi di

431
00:33:30,400 --> 00:33:34,445
implementare il lato server e il lato client.

432
00:33:34,445 --> 00:33:39,685
Nell' applicazione angolare che siamo implementati nella nostra specializzazione angolare,

433
00:33:39,685 --> 00:33:43,470
avevamo usato il metodo sotto-documento per la

434
00:33:43,470 --> 00:33:47,560
gestione dei commenti nella nostra applicazione client angolare.

435
00:33:47,560 --> 00:33:50,050
Quindi, il server API resto è stato

436
00:33:50,050 --> 00:33:54,090
implementato in modo tale che fosse più adatto per il client Angular.

437
00:33:54,090 --> 00:34:00,600
Ma per i client React dal momento che abbiamo mantenuto i commenti indipendenti dai piatti,

438
00:34:00,600 --> 00:34:03,985
e quindi utilizzare l'ID del piatto all'interno del commento,

439
00:34:03,985 --> 00:34:09,300
quindi abbiamo bisogno di ristrutturare il nostro server API di riposo,

440
00:34:09,300 --> 00:34:16,835
quindi è che abbiamo un endpoint di commento separato indipendente dall'endpoint piatti.

441
00:34:16,835 --> 00:34:22,310
Quindi, abbiamo bisogno di ristrutturare il nostro codice nel server

442
00:34:22,310 --> 00:34:29,140
per introdurre l'endpoint API REST /comments in questa fase.

443
00:34:29,140 --> 00:34:30,600
Quindi, per farlo,

444
00:34:30,600 --> 00:34:37,540
andiamo avanti e implementiamo un nuovo modello chiamato come comment.js.

445
00:34:37,540 --> 00:34:39,260
Quindi, andando nei modelli,

446
00:34:39,260 --> 00:34:45,790
lasciami implementare un nuovo file chiamato comments.js.

447
00:34:47,220 --> 00:34:50,015
Nel file comments.js,

448
00:34:50,015 --> 00:34:56,110
abbiamo intenzione di spostare il CommentSchema dal

449
00:34:56,110 --> 00:35:02,660
file dishes.js nel file comments.js e quindi rimuoverlo completamente dal file dishes.js.

450
00:35:02,660 --> 00:35:03,900
Ma prima di farlo,

451
00:35:03,900 --> 00:35:08,770
abbiamo bisogno di copiare la mangusta e lo schema da qui,

452
00:35:08,770 --> 00:35:13,860
quindi lasciami copiare questo da dishes.js in comment.js.

453
00:35:13,860 --> 00:35:16,590
Dopodiché, andando in dishes.js,

454
00:35:16,590 --> 00:35:21,040
lasciami tagliare completamente questo CommentSchema da qui,

455
00:35:21,040 --> 00:35:28,300
perché avremo questo separatamente nel modello dei commenti qui.

456
00:35:28,300 --> 00:35:33,070
Quindi, spostiamolo nel modello dei commenti e quindi incollalo qui.

457
00:35:33,070 --> 00:35:35,050
Ma ovviamente questo non è il completo,

458
00:35:35,050 --> 00:35:37,870
aggiorneremo un po 'il CommentSchema.

459
00:35:37,870 --> 00:35:39,300
Ma prima di farlo,

460
00:35:39,300 --> 00:35:43,455
tornare al file dishes.js e nel file dei piatti,

461
00:35:43,455 --> 00:35:47,925
rimuoveremo i commenti dal DishesChema,

462
00:35:47,925 --> 00:35:51,510
perché stiamo andando a memorizzare il contenuto separatamente dai

463
00:35:51,510 --> 00:35:55,550
piatti in questa versione del nostro server.

464
00:35:55,550 --> 00:36:00,450
Quindi, è così che aggiorneremo il modello di piatti qui.

465
00:36:00,450 --> 00:36:08,180
Quindi, abbiamo rimosso completamente i commenti dal modello piatti qui.

466
00:36:08,180 --> 00:36:10,270
Entrando nel modello dei commenti,

467
00:36:10,270 --> 00:36:15,355
quindi ora vediamo che abbiamo il CommentSchema implementato qui.

468
00:36:15,355 --> 00:36:19,525
Ma in aggiunta, nei CommentsChema,

469
00:36:19,525 --> 00:36:23,330
ora dobbiamo puntare esplicitamente al

470
00:36:23,330 --> 00:36:28,885
piatto specifico per il quale questo commento è il commento corrispondente.

471
00:36:28,885 --> 00:36:30,700
Ora, qui è dove

472
00:36:30,700 --> 00:36:37,435
la nostra popolazione di manguste e

473
00:36:37,435 --> 00:36:41,580
il modo in cui conserviamo gli ID degli oggetti vengono in nostro soccorso.

474
00:36:41,580 --> 00:36:45,860
Quindi, aggiorneremo il CommentSchema dicendo che avremo la valutazione,

475
00:36:45,860 --> 00:36:47,800
il commento e l'autore qui.

476
00:36:47,800 --> 00:36:49,110
Oltre all'autore,

477
00:36:49,110 --> 00:36:56,080
introdurremo un altro campo chiamato come il piatto qui che è

478
00:36:56,080 --> 00:37:05,540
del tipo: mangoose.Schema types.ObjectID,

479
00:37:06,390 --> 00:37:19,870
e quindi questo farà riferimento al piatto qui.

480
00:37:19,870 --> 00:37:29,060
Quindi, questo sarebbe un riferimento oggetto al modello piatto qui,

481
00:37:29,060 --> 00:37:32,255
e quindi con questa modifica ora

482
00:37:32,255 --> 00:37:36,640
i nostri commenti conterranno il campo di valutazione, il campo di commento,

483
00:37:36,640 --> 00:37:42,355
l'autore che è di nuovo un riferimento all'utente corrispondente,

484
00:37:42,355 --> 00:37:47,660
e quindi il campo piatto che è un riferimento al corrispondente piatto qui.

485
00:37:47,660 --> 00:37:50,060
Quindi, il che significa che ora dovremo

486
00:37:50,060 --> 00:37:53,640
popolare i commenti sia con l'autore che con il campo piatto.

487
00:37:53,640 --> 00:37:55,565
Una volta completato questo,

488
00:37:55,565 --> 00:38:01,585
allora diremo var Commenti

489
00:38:01,585 --> 00:38:09,910
mongoose.model e chiameremo questo 'Commento',

490
00:38:09,910 --> 00:38:16,765
e poi questo utilizza il CommentSchema che abbiamo appena definito qui,

491
00:38:16,765 --> 00:38:21,970
e poi abbiamo bisogno di esportare questo da qui,

492
00:38:21,970 --> 00:38:25,280
il comments.model da qui.

493
00:38:25,280 --> 00:38:28,395
Quindi, ora che abbiamo introdotto il comments.model,

494
00:38:28,395 --> 00:38:35,045
allora andremo avanti e quindi introdurre un nuovo Router chiamato come CommentRouter.

495
00:38:35,045 --> 00:38:37,060
Quindi, per introdurre il router dei commenti,

496
00:38:37,060 --> 00:38:39,630
andiamo nelle rotte qui

497
00:38:39,630 --> 00:38:45,990
e quindi creare un nuovo file denominato commentRouter.js.

498
00:38:47,090 --> 00:38:52,415
Nel commentRouter.js, lasciami copiare alcune cose

499
00:38:52,415 --> 00:38:59,890
da DishRouter.

500
00:38:59,890 --> 00:39:07,720
Quindi, avremo questi commenti qui,

501
00:39:07,720 --> 00:39:14,865
quindi lasciami copiare su queste cose da e anche,

502
00:39:14,865 --> 00:39:21,070
mentre sono a questo fammi solo copiare questi anche fino a quel punto,

503
00:39:21,070 --> 00:39:24,625
e poi aggiornerò un po 'più tardi.

504
00:39:24,625 --> 00:39:26,680
Quindi, andando nel CommentRouter,

505
00:39:26,680 --> 00:39:28,040
abbiamo bisogno di tutte queste parti,

506
00:39:28,040 --> 00:39:33,640
quindi diremo Com, Express, BodyParser, mangusta

507
00:39:33,640 --> 00:39:37,735
, autenticare, cors, e poi

508
00:39:37,735 --> 00:39:46,490
importeremo commenti da modelli/commenti.

509
00:39:49,950 --> 00:40:00,460
Quindi chiameremo questo come CommentRouter che è un Express.Router qui.

510
00:40:02,060 --> 00:40:11,950
Quindi diremo CommentRouter usa BodyParser,

511
00:40:11,950 --> 00:40:17,915
e quindi questo sarebbe ora diventato percorso CommentRouter.

512
00:40:17,915 --> 00:40:22,030
Ora, abbiamo bisogno di andare nel DishRouter e quindi

513
00:40:22,030 --> 00:40:27,200
rimuovere tutte le parti che si riferiscono ai commenti qui.

514
00:40:27,200 --> 00:40:34,330
Quindi, lasciami tagliare questa parte e poi riutilizzeremo questi per il nostro CommentRouter.

515
00:40:34,330 --> 00:40:38,200
Quindi, tutti questi non sono più necessari nel DishRouter.

516
00:40:38,200 --> 00:40:42,080
Quindi, ho intenzione di rimuovere tutto questo da DishRouter qui,

517
00:40:42,080 --> 00:40:43,770
quindi lasciami tagliare fuori,

518
00:40:43,770 --> 00:40:48,715
tutto ciò che riguarda il percorso dei commenti dal DishRouter,

519
00:40:48,715 --> 00:40:50,770
quindi andremo nel CommentRouter,

520
00:40:50,770 --> 00:40:54,405
e poi lasciami andare avanti e incollarlo qui,

521
00:40:54,405 --> 00:40:57,100
quindi lo modificheremo qui.

522
00:40:57,100 --> 00:41:02,660
Quindi dopo questo, abbiamo bisogno di esportare il CommentRouter.

523
00:41:05,160 --> 00:41:08,205
Quindi, esporterà il CommentRouter per noi.

524
00:41:08,205 --> 00:41:12,060
Ma ovviamente, questo codice non è completamente accurato.

525
00:41:12,060 --> 00:41:14,995
Quindi, dobbiamo andare avanti e risolvere questo codice qui.

526
00:41:14,995 --> 00:41:16,585
Quindi, per questo codice,

527
00:41:16,585 --> 00:41:20,180
ora ci rendiamo conto che questo non è il percorso DishRouter,

528
00:41:20,180 --> 00:41:21,785
invece che dovrebbe essere

529
00:41:21,785 --> 00:41:27,700
il/endpoint perché stiamo

530
00:41:27,700 --> 00:41:33,685
andando a montare questo nell'endpoint /comments qui.

531
00:41:33,685 --> 00:41:35,685
Quindi, diremo CommentRouter,

532
00:41:35,685 --> 00:41:39,859
e poi le opzioni corsWithOptions (req,

533
00:41:39,859 --> 00:41:42,550
res) che rimane come tale lì,

534
00:41:42,550 --> 00:41:48,429
e poi get cors.cors e quindi req.res,

535
00:41:48,429 --> 00:41:52,460
e poi questo diventerà commenti.

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

537
00:42:00,600 --> 00:42:05,330
Quindi, questo sarebbe commenti.Find

538
00:42:07,050 --> 00:42:17,080
e req.query qui.

539
00:42:17,080 --> 00:42:20,920
Quindi, quando vengono trovati i commenti

540
00:42:20,920 --> 00:42:22,974
, allora, a questo punto,

541
00:42:22,974 --> 00:42:25,940
popoleremo l'autore,

542
00:42:26,880 --> 00:42:30,430
già lì, popoleremo qui.

543
00:42:30,430 --> 00:42:33,380
Quindi, ho intenzione di rimuovere questo comments.author, e

544
00:42:33,380 --> 00:42:37,410
poi, semplicemente popolare l'autore qui.

545
00:42:37,410 --> 00:42:44,425
Quindi, questo ci darebbe dei commenti qui.

546
00:42:44,425 --> 00:42:49,310
Quindi, diremo, questo può essere semplificato in modo significativo.

547
00:42:49,310 --> 00:42:53,835
Quindi, l'errore di cattura è lì comunque.

548
00:42:53,835 --> 00:43:00,805
Quindi, quando arriverà il commento, tornerà semplicemente.

549
00:43:00,805 --> 00:43:03,910
Scusa, dovrebbe esserlo.

550
00:43:03,910 --> 00:43:06,525
Quindi, se per ottenere,

551
00:43:06,525 --> 00:43:09,305
quando otteniamo i commenti,

552
00:43:09,305 --> 00:43:13,760
comments.Find req.query, .populate autore qui,

553
00:43:13,760 --> 00:43:18,010
e poi, diremo, .then commenti,

554
00:43:18,010 --> 00:43:21,619
e poi, diremo, res.StatusCode 200,

555
00:43:21,619 --> 00:43:27,605
SetHeader, e poi, restituiremo i commenti da qui,

556
00:43:27,605 --> 00:43:30,850
res.json commenti da qui.

557
00:43:30,850 --> 00:43:36,970
Ora, non sto popolando i piatti qui perché non ho esplicitamente bisogno

558
00:43:36,970 --> 00:43:45,300
dei piatti nel modo in cui uso queste informazioni nel mio cliente reattivo.

559
00:43:45,300 --> 00:43:46,840
Ho solo bisogno dell'ID del piatto,

560
00:43:46,840 --> 00:43:49,085
e l'ID del piatto è già presente lì,

561
00:43:49,085 --> 00:43:55,310
e questo è abbastanza buono per me da usare questi dati nel mio client reattivo.

562
00:43:55,310 --> 00:43:57,685
Quindi, ho intenzione di lasciarlo come tale lì.

563
00:43:57,685 --> 00:43:59,530
Ho intenzione di popolare le informazioni

564
00:43:59,530 --> 00:44:02,910
dell'autore solo lì perché abbiamo bisogno delle informazioni complete dell'autore

565
00:44:02,910 --> 00:44:08,930
ogni volta che rendiamo un elemento di commento nel nostro client di reazione.

566
00:44:08,930 --> 00:44:12,655
Quindi, il get verrà aggiornato in questo modo qui.

567
00:44:12,655 --> 00:44:22,015
Per il post corsWithOptions,

568
00:44:22,015 --> 00:44:26,070
diremo, authenticate.verifyUser req, res, next.

569
00:44:26,070 --> 00:44:29,540
Ovviamente, per un commento da pubblicare,

570
00:44:29,540 --> 00:44:38,315
è necessario che l'autore sia un utente registrato valido.

571
00:44:38,315 --> 00:44:42,910
Solo allora, permetterai all'utente di pubblicare un commento.

572
00:44:42,910 --> 00:44:49,020
Quindi, il commento stesso arriva nel corpo del messaggio di richiesta in arrivo.

573
00:44:49,020 --> 00:44:51,810
Quindi, in primo luogo, controlleremo il corpo

574
00:44:51,810 --> 00:44:58,865
per assicurarci che il commento sia incluso nel corpo qui.

575
00:44:58,865 --> 00:45:03,730
Quindi, qui, ho intenzione di rimuovere tutte queste parti, e poi,

576
00:45:03,730 --> 00:45:06,100
semplificarlo ulteriormente, e quindi,

577
00:45:06,100 --> 00:45:09,430
implementarlo correttamente lì.

578
00:45:09,430 --> 00:45:17,755
Quindi, proprio a questo punto, diremo,

579
00:45:17,755 --> 00:45:27,465
se req.body non è uguale a null,

580
00:45:27,465 --> 00:45:35,030
quindi il che significa che c'è un commento che è racchiuso all'interno del corpo.

581
00:45:37,380 --> 00:45:45,025
Quindi, lasciami tagliare questo e spostare questo nella parte if qui,

582
00:45:45,025 --> 00:45:47,155
e poi, lo modificheremo qui.

583
00:45:47,155 --> 00:45:52,245
Quindi, se il corpo non esiste,

584
00:45:52,245 --> 00:45:56,140
allora causeremo un errore.

585
00:45:56,140 --> 00:46:01,220
Quindi, diremo, errare nuovo errore,

586
00:46:01,500 --> 00:46:08,965
Commento non trovato nel corpo della richiesta.

587
00:46:08,965 --> 00:46:12,440
Quindi, solleveremo questo errore qui.

588
00:46:12,450 --> 00:46:16,425
Lo stato di errore è 404.

589
00:46:16,425 --> 00:46:20,385
Quindi, diremo, restituire il prossimo errore.

590
00:46:20,385 --> 00:46:26,560
Quindi, gestiamo la parte di errore qui se il corpo

591
00:46:26,560 --> 00:46:33,280
non contiene le informazioni di commento appropriate.

592
00:46:33,280 --> 00:46:35,450
Se contiene, allora, ovviamente,

593
00:46:35,450 --> 00:46:38,170
quello che faremo dopo è,

594
00:46:38,170 --> 00:46:48,310
diremo, req.body.author è req.user. _id.

595
00:46:50,420 --> 00:46:55,610
Il motivo per cui stiamo facendo questo è che ricordiamo che se si

596
00:46:55,610 --> 00:46:59,950
tratta di un utente registrato e l'utente ha effettuato l'accesso,

597
00:46:59,950 --> 00:47:03,050
allora il req.user conterrà le informazioni utente.

598
00:47:03,050 --> 00:47:07,260
Quindi, ho solo bisogno dell'ID dell'utente attualmente connesso.

599
00:47:07,260 --> 00:47:10,310
Quindi, diremo, req.user. _id, e quindi,

600
00:47:10,310 --> 00:47:14,645
imposteremo il req.body.author su req.user. _id.

601
00:47:14,645 --> 00:47:20,070
Ora, l'utente di verifica si assicurerà automaticamente che se atterri a questo punto,

602
00:47:20,070 --> 00:47:25,710
allora si avrebbe ovviamente un utente che ha effettuato correttamente l'accesso.

603
00:47:25,710 --> 00:47:28,605
Altrimenti, ciò avrebbe già causato il problema lì.

604
00:47:28,605 --> 00:47:30,260
Quindi, quando raggiungi a questo punto,

605
00:47:30,260 --> 00:47:37,660
avresti un utente valido che ha già effettuato l'accesso al sistema in lì.

606
00:47:37,660 --> 00:47:43,460
Quindi, questo è dove saresti in grado di farlo ora.

607
00:47:43,460 --> 00:47:46,040
Quindi, quello che stiamo facendo è che il campo autore, lo

608
00:47:46,040 --> 00:47:50,625
stiamo impostando esplicitamente nell'ID dell'utente qui in modo che

609
00:47:50,625 --> 00:47:57,490
il req.body contenga le restanti parti del commento.

610
00:47:57,490 --> 00:48:01,315
Quindi, come ti rendi conto, il commento contiene

611
00:48:01,315 --> 00:48:04,540
la valutazione, il commento stesso e l'autore e i campi piatto.

612
00:48:04,540 --> 00:48:11,510
Quindi, le parti rimanenti dovrebbero essere state riempite dall'utente.

613
00:48:11,510 --> 00:48:14,730
La valutazione, il commento

614
00:48:14,730 --> 00:48:17,775
e le informazioni sui piatti devono essere già

615
00:48:17,775 --> 00:48:20,840
inseriti nel corpo del messaggio di richiesta in arrivo.

616
00:48:20,840 --> 00:48:23,460
La parte dell'autore è lasciata libera lì,

617
00:48:23,460 --> 00:48:28,380
che inseriremo esplicitamente a questo punto nel corpo qui.

618
00:48:28,380 --> 00:48:32,515
Quindi, ora, il req.body conterrà l'intera informazione del commento.

619
00:48:32,515 --> 00:48:34,440
Quindi, a questo punto,

620
00:48:34,440 --> 00:48:43,400
invece di fare questo, diremo, commenti.Crea.

621
00:48:44,550 --> 00:48:49,940
Usando il req.body, creeremo i commenti qui.

622
00:48:50,010 --> 00:48:53,304
Quindi, questo restituirà

623
00:48:53,304 --> 00:48:58,735
il commento corrispondente al commento che abbiamo appena inserito qui.

624
00:48:58,735 --> 00:49:00,755
Ora, una volta che il commento è tornato,

625
00:49:00,755 --> 00:49:07,050
allora dovremmo fare comments.findById.

626
00:49:07,050 --> 00:49:09,680
Ora, il motivo per cui dobbiamo farlo è perché

627
00:49:09,680 --> 00:49:13,070
dobbiamo popolare le informazioni dell'autore qui.

628
00:49:13,780 --> 00:49:18,144
Quindi, diremo, FindById commenti. _id,

629
00:49:18,144 --> 00:49:26,155
quindi, popoleremo le informazioni dell'autore nel commento stesso.

630
00:49:26,155 --> 00:49:34,610
Quindi, diremo, poi commentare.

631
00:49:36,570 --> 00:49:41,115
Ora, ovviamente, qui, troverai che il commento

632
00:49:41,115 --> 00:49:44,880
esisterà perché abbiamo appena inserito quel commento in posizione lì.

633
00:49:44,880 --> 00:49:54,470
Quindi, qui, torneremo semplicemente, res.statusCode è 200,

634
00:49:54,900 --> 00:50:10,040
Res.SetHeader è Content-Type, application/json.

635
00:50:14,610 --> 00:50:18,430
Il commento stesso dirà, res.json, quindi,

636
00:50:18,430 --> 00:50:21,745
restituirà il commento a questo punto.

637
00:50:21,745 --> 00:50:26,255
Quindi, questo è il modo in cui gestiremo l'inserimento di

638
00:50:26,255 --> 00:50:30,805
un nuovo commento nel nostro lato client qui.

639
00:50:30,805 --> 00:50:33,925
Per il put, come ti rendi conto,

640
00:50:33,925 --> 00:50:38,360
non sarai in grado di fare un put sui punti finali /commenti/.

641
00:50:38,360 --> 00:50:47,610
Quindi, diremo, operazione PUT non supportata su/comments/ punto finale.

642
00:50:52,050 --> 00:50:56,180
E' questo il punto. Questo è il messaggio che restituirai.

643
00:50:56,180 --> 00:50:58,570
Quindi, StatusCode è 403,

644
00:50:58,570 --> 00:51:02,610
e quindi, l'operazione PUT non supportata su/comments/.

645
00:51:02,610 --> 00:51:05,260
Ora, quando facciamo una cancellazione,

646
00:51:13,230 --> 00:51:22,840
lasciami solo tagliare questo da qui, e poi, diremo,

647
00:51:30,440 --> 00:51:32,835
commenti.Rimuovere.

648
00:51:32,835 --> 00:51:37,710
scritto vuoto. Pertanto, quando esegui un'eliminazione sull'endpoint dei commenti della barra,

649
00:51:37,710 --> 00:51:40,990
rimuoverai tutti i commenti dal tuo sistema.

650
00:51:40,990 --> 00:51:43,680
Quindi, questa è un'operazione molto pericolosa, e quindi,

651
00:51:43,680 --> 00:51:48,990
non dovresti farlo normalmente.

652
00:51:48,990 --> 00:51:53,860
Quindi, permetteremo solo all'amministratore di eseguire tale operazione.

653
00:51:53,860 --> 00:51:59,410
Quindi, rimuoveremo tutti i commenti da lì.

654
00:51:59,410 --> 00:52:01,940
Quindi, quando ottieni la risposta,

655
00:52:01,940 --> 00:52:07,700
diremo res.statusCode 200.

656
00:52:07,700 --> 00:52:11,080
Quindi, lasciami copiare queste parti qui,

657
00:52:12,090 --> 00:52:18,130
e poi venite a incollarle qui.

658
00:52:18,130 --> 00:52:21,330
Quindi, diremo, commenti.remove.

659
00:52:21,330 --> 00:52:30,480
Quindi risposta res.statusCode 200 applicazione json e quindi res.json (risposta) qui.

660
00:52:30,480 --> 00:52:33,100
Quindi, è così che gestiamo la cancellazione.

661
00:52:33,100 --> 00:52:37,280
Operazione di eliminazione sull'endpoint dei commenti della barra.

662
00:52:37,280 --> 00:52:43,135
Ora, il prossimo percorso è il router dei commenti.

663
00:52:43,135 --> 00:52:49,490
Quindi, qui diremo CommentRouter.Route e

664
00:52:49,490 --> 00:52:56,820
il punto finale qui sarebbe la barra CommentId.

665
00:53:01,190 --> 00:53:05,580
Quindi, qui le opzioni rimarranno come tali.

666
00:53:05,580 --> 00:53:09,760
Quindi per il get sul router corrente,

667
00:53:09,760 --> 00:53:20,455
per il get diremo, comments.findById (req.params.

668
00:53:20,455 --> 00:53:25,040
Questo sarebbe CommentId.

669
00:53:25,380 --> 00:53:31,029
Quindi, una volta trovato il commento specifico,

670
00:53:31,029 --> 00:53:37,525
allora popoleremo solo l'autore da lì.

671
00:53:37,525 --> 00:53:39,985
Poi una volta popolato l'autore,

672
00:53:39,985 --> 00:53:45,830
allora diremo, quindi commentare.

673
00:53:47,880 --> 00:53:51,310
Ora, tutta questa parte non è necessaria qui,

674
00:53:51,310 --> 00:53:54,440
quindi ho intenzione di cancellare la parte.

675
00:53:54,480 --> 00:54:00,985
Anche questa non è la cosa appropriata qui.

676
00:54:00,985 --> 00:54:04,540
Quindi, fammi rinominare il codice.

677
00:54:04,540 --> 00:54:08,990
Quindi, diremo per ottenere comments.FindById,

678
00:54:11,550 --> 00:54:15,385
quindi popolare l'autore,

679
00:54:15,385 --> 00:54:20,365
quindi commentare, res.StatusCode è 200, SetHeader.

680
00:54:20,365 --> 00:54:22,435
Quindi il resto sono json.

681
00:54:22,435 --> 00:54:29,960
Saremo semplicemente restituendo i commenti qui.

682
00:54:39,240 --> 00:54:46,750
Quindi, restituiremo il commento a questo punto, res.json (commento).

683
00:54:46,750 --> 00:54:49,340
Troverai il commento specifico

684
00:54:49,340 --> 00:54:52,415
e poi restituirai quel commento per il post.

685
00:54:52,415 --> 00:54:55,185
Per la post-operazione, come ti rendi conto,

686
00:54:55,185 --> 00:54:56,900
la post-operazione non è

687
00:54:56,900 --> 00:55:06,740
consentita nei commenti CommentId.

688
00:55:10,080 --> 00:55:13,805
Quindi, questo è il messaggio che invieremo,

689
00:55:13,805 --> 00:55:19,110
operazione POST non supportata sui commenti barra commentId.

690
00:55:19,110 --> 00:55:23,640
Quindi, questo è il messaggio che diremo per il put.

691
00:55:23,640 --> 00:55:33,730
Ora, per il put, diremo commenti.Trova dove Id (req.params.CommentId).

692
00:55:34,890 --> 00:55:39,230
Quindi, troveremo il commento lì,

693
00:55:40,890 --> 00:55:48,070
e ci commento, quindi per il put.

694
00:55:48,070 --> 00:55:50,805
Quindi, troveremo il commento lì,

695
00:55:50,805 --> 00:55:53,400
e poi diremo per i commenti.

696
00:55:53,400 --> 00:55:55,305
Quindi, se troviamo il commento,

697
00:55:55,305 --> 00:56:07,080
se il commento non è nullo,

698
00:56:07,080 --> 00:56:19,455
allora controlleremo anche se comment.author.

699
00:56:19,455 --> 00:56:32,625
In caso contrario, comment.arthur è uguale a (req.user. _id).

700
00:56:32,625 --> 00:56:38,095
Quindi, stiamo controllando incrociando per assicurarci che

701
00:56:38,095 --> 00:56:43,755
il comments.author sia lo stesso dell'utente corrente.

702
00:56:43,755 --> 00:56:50,950
Solo l'utente corrente che ha effettuato l'accesso - se l'utente è uguale all'autore dei commenti,

703
00:56:50,950 --> 00:56:53,760
l'utente sarà autorizzato ad aggiornare.

704
00:56:53,760 --> 00:56:57,190
Quindi, questa è la prima cosa che controlleremo.

705
00:56:57,190 --> 00:57:01,900
Quindi, commenti, quindi commenta.author.equal a rec.user. _id.

706
00:57:01,900 --> 00:57:07,860
In caso contrario, dirai che non sei autorizzato ad aggiornare questo commento.

707
00:57:07,860 --> 00:57:10,859
Come vedi il.403,

708
00:57:10,859 --> 00:57:13,090
quindi restituisce il prossimo errore qui.

709
00:57:13,090 --> 00:57:16,705
Quindi, creeremo l'errore lì.

710
00:57:16,705 --> 00:57:21,800
Quindi dopo questo, diremo

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

712
00:57:40,010 --> 00:57:42,215
Questo è importante.

713
00:57:42,215 --> 00:57:45,580
Ora, questi due non sono necessari qui,

714
00:57:45,580 --> 00:57:51,385
perché stiamo salvando direttamente il commento.

715
00:57:51,385 --> 00:58:05,980
Poi pillole, diremo commenti.FindByidAndUpdate

716
00:58:05,980 --> 00:58:14,965
e req.Params.CommentId.

717
00:58:14,965 --> 00:58:18,395
Quindi, troveremo quel commento specifico,

718
00:58:18,395 --> 00:58:21,925
perché ci è già stato fornito l'ID commento.

719
00:58:21,925 --> 00:58:27,205
Quindi, faremo commenti findById req.Params.CommentId.

720
00:58:27,205 --> 00:58:30,260
Poi diremo poi (commento).

721
00:58:32,730 --> 00:58:38,705
Quando si fornisce il Req.Params.CommentId,

722
00:58:38,705 --> 00:58:42,275
dovremo fornire esplicitamente il secondo parametro,

723
00:58:42,275 --> 00:58:45,825
che è ciò che vogliamo cambiare.

724
00:58:45,825 --> 00:58:52,285
Quindi, diremo $ set: req.body.

725
00:58:52,285 --> 00:58:54,970
Quindi, il secondo parametro, essenzialmente,

726
00:58:54,970 --> 00:58:58,740
ti dice quale parte stai cambiando.

727
00:58:58,740 --> 00:59:03,710
Ora, dal momento che ci è stato fornito il corpo contenente il commento aggiornato,

728
00:59:03,710 --> 00:59:09,140
stiamo solo andando ad aggiornare l'intero commento stesso.

729
00:59:09,510 --> 00:59:18,205
Poi l'altra parte che chiederemo è nuova: vera.

730
00:59:18,205 --> 00:59:23,240
Quindi, questo garantirà che il commento aggiornato verrà restituito

731
00:59:23,240 --> 00:59:29,815
nella tana di questa chiamata ai comments.findByidundUpdate.

732
00:59:29,815 --> 00:59:32,565
Quindi, diremo poi commenti.

733
00:59:32,565 --> 00:59:35,214
Quando questo commento viene restituito,

734
00:59:35,214 --> 00:59:38,440
allora diremo comments.findById (commento. _id).

735
00:59:46,200 --> 00:59:51,460
Quindi popolare l'autore lì.

736
00:59:51,460 --> 00:59:53,785
Popoleremo l'autore lì,

737
00:59:53,785 --> 00:59:58,490
e poi diremo poi commentare.

738
00:59:58,700 --> 01:00:09,680
Quindi, vedi che otterremo il commento e poi restituiremo il commento a questo punto.

739
01:00:09,680 --> 01:00:13,095
Quindi, è così che aggiorneremo il commento.

740
01:00:13,095 --> 01:00:17,395
Quindi, questa è la situazione in cui il commento non è nullo.

741
01:00:17,395 --> 01:00:20,625
Quindi, questa istruzione if per il commento non è nullo.

742
01:00:20,625 --> 01:00:23,785
Quindi, l'altro se parte,

743
01:00:23,785 --> 01:00:29,020
ora questo non è applicabile,

744
01:00:29,020 --> 01:00:33,325
quindi diremo altro, errore.

745
01:00:33,325 --> 01:00:35,470
L' errore in questo caso.

746
01:00:35,470 --> 01:00:37,825
Quindi, se il commento è nullo,

747
01:00:37,825 --> 01:00:40,850
significa che non abbiamo trovato il commento lì dentro,

748
01:00:40,850 --> 01:00:43,650
quindi non puoi modificare un commento inesistente.

749
01:00:43,650 --> 01:00:44,805
Quindi diremo err,

750
01:00:44,805 --> 01:00:54,700
nuovo commento di errore req.params.CommentId non trovato e quindi restituiremo l'errore.

751
01:00:54,700 --> 01:01:01,255
Quindi, è così che gestiremo la parte put del nostro commento qui,

752
01:01:01,255 --> 01:01:04,099
e poi finalmente l'eliminazione.

753
01:01:06,120 --> 01:01:11,130
Per l'eliminazione, di nuovo dovremo prima trovare

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

755
01:01:12,900 --> 01:01:25,720
e quindi commentare.

756
01:01:25,720 --> 01:01:28,150
Quindi, cercheremo il commento.

757
01:01:28,150 --> 01:01:34,160
Quindi, prima controlleremo se il commento non è uguale a null.

758
01:01:36,180 --> 01:01:39,955
E' importante controllare qui.

759
01:01:39,955 --> 01:01:50,990
Quindi, la parte successiva che controlleremo è se il comment.author è uguale a req.user. _id.

760
01:01:58,830 --> 01:02:03,400
Ci assicuriamo che l'utente che sta tentando di eliminare

761
01:02:03,400 --> 01:02:08,060
questo commento sia esattamente lo stesso utente che ha inserito il commento in primo luogo. In

762
01:02:08,060 --> 01:02:10,750
caso contrario, quindi se questa è la situazione,

763
01:02:10,750 --> 01:02:13,920
vedrai 'Non sei autorizzato a cancellare questo commento! '

764
01:02:13,920 --> 01:02:16,365
E poi restituire lo stato lì.

765
01:02:16,365 --> 01:02:20,920
Poi giù qui sotto,

766
01:02:20,920 --> 01:02:41,310
diremo comments.FindByidAndRemove qui.

767
01:02:41,310 --> 01:02:48,750
Quindi, diremo comments.findByIdAndRemove (req.params.CommentId),

768
01:02:48,750 --> 01:02:54,035
quindi otterremo una risposta dal commento.

769
01:02:54,035 --> 01:02:55,630
Quindi, a questo punto,

770
01:02:55,630 --> 01:02:59,830
diremo semplicemente, res.statusCode.

771
01:02:59,830 --> 01:03:05,365
Quindi diremo comments.FindByIdAndRemove quindi risposta.

772
01:03:05,365 --> 01:03:07,210
Se viene rimosso correttamente,

773
01:03:07,210 --> 01:03:10,915
diremo 200 e quindi res.json

774
01:03:10,915 --> 01:03:17,260
risposta qui e prenderemo anche l'errore a questo punto.

775
01:03:17,260 --> 01:03:25,195
Quindi, lasciami copiare qui e poi includeremo la cattura dell'errore a questo punto.

776
01:03:25,195 --> 01:03:28,895
Quindi, questa è la prima cosa che controlleremo.

777
01:03:28,895 --> 01:03:33,500
Ci assicureremo che il commento non sia uguale a null.

778
01:03:33,630 --> 01:03:38,360
Altrimenti, quindi questa è l'altra parte.

779
01:03:39,810 --> 01:03:44,170
Quindi, questa è l'altra parte dell'errore if else

780
01:03:44,170 --> 01:03:48,040
nuovo commento req.params.CommentId non trovato e quindi

781
01:03:48,040 --> 01:03:56,220
404 e invia la parte else per noi e quindi la parte allora gestirà in modo appropriato.

782
01:03:56,220 --> 01:04:01,460
Quindi, queste sono le modifiche che apportiamo per il router dei commenti qui.

783
01:04:01,460 --> 01:04:05,025
Quindi, stiamo gestendo il post get put ed eliminare per

784
01:04:05,025 --> 01:04:10,330
i commenti barra e commenti barra punto barra commentID impatto.

785
01:04:10,330 --> 01:04:12,495
Quindi, una volta completato questo,

786
01:04:12,495 --> 01:04:17,500
allora abbiamo bisogno di includere questo nel file app.js.

787
01:04:17,500 --> 01:04:27,345
Quindi, andremo nel file app.js e poi diremo

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

789
01:04:31,130 --> 01:04:42,280
richiede routes/CommentRouter.

790
01:04:42,280 --> 01:04:45,960
Quindi, abbiamo il router commento qui e poi andremo

791
01:04:45,960 --> 01:04:49,390
giù nel file app.js qui sotto e

792
01:04:49,390 --> 01:04:54,610
poi diremo app.use

793
01:04:55,040 --> 01:05:04,695
slash commenti, CommentRouter qui.

794
01:05:04,695 --> 01:05:07,365
Questo è tutto. Quindi ora,

795
01:05:07,365 --> 01:05:09,390
il mio router di commento è pronto.

796
01:05:09,390 --> 01:05:12,935
Quindi, andiamo avanti e salviamo tutte le modifiche.

797
01:05:12,935 --> 01:05:19,020
Quindi il nostro server è ora aggiornato

798
01:05:19,020 --> 01:05:24,420
al fine di gestire tutte le richieste dei nostri clienti React qui.

799
01:05:24,420 --> 01:05:27,800
Ora, se vuoi fare il modo alternativo, cioè,

800
01:05:27,800 --> 01:05:34,120
hai i tuoi commenti come sotto-documenti del tuo piatto e poi vuoi gestirlo,

801
01:05:34,120 --> 01:05:37,680
allora dovrai aggiornare il client React per essere in

802
01:05:37,680 --> 01:05:42,185
grado di utilizzare i commenti dall'interno di ogni piatto in modo appropriato.

803
01:05:42,185 --> 01:05:44,830
Questo sarà lasciato come un esercizio per voi.

804
01:05:44,830 --> 01:05:48,920
Pensa a come progettare il tuo client reattivo in modo tale che

805
01:05:48,920 --> 01:05:53,465
funzioni molto bene con la versione precedente

806
01:05:53,465 --> 01:06:03,735
del server che aveva i commenti come sotto-documenti dei tuoi piatti stessi.

807
01:06:03,735 --> 01:06:07,065
Ora, questo sarà un modo interessante di implementarlo.

808
01:06:07,065 --> 01:06:10,480
Naturalmente, è un po 'più complicato del modo in cui abbiamo

809
01:06:10,480 --> 01:06:14,965
implementato il client React dove abbiamo mantenuto i commenti indipendenti dai

810
01:06:14,965 --> 01:06:20,840
piatti, ma poi il lavoro aggiuntivo è quindi

811
01:06:20,840 --> 01:06:22,910
la responsabilità del lato client perché è necessario selezionare

812
01:06:22,910 --> 01:06:26,765
i commenti appropriati quando si mostra un piatto specifico.

813
01:06:26,765 --> 01:06:30,370
È necessario selezionare i commenti da tutti i commenti qui.

814
01:06:30,370 --> 01:06:35,170
Quindi, questo è un lavoro aggiuntivo che il nostro cliente React fa a causa

815
01:06:35,170 --> 01:06:40,680
del fatto che abbiamo separato i commenti dai piatti stessi.

816
01:06:40,680 --> 01:06:46,165
Allo stesso modo, se puoi riprogettare il tuo cliente angolare per essere in grado di

817
01:06:46,165 --> 01:06:51,775
affrontare la situazione in cui i commenti sono tenuti indipendenti dai tuoi piatti.

818
01:06:51,775 --> 01:06:56,020
Ora, quindi questi sono tutti esercizi che puoi fare per vedere come puoi

819
01:06:56,020 --> 01:07:01,210
estendere le tue applicazioni client per gestire qualsiasi tipo di server,

820
01:07:01,210 --> 01:07:04,430
i due diversi tipi di server lì.

821
01:07:04,860 --> 01:07:11,480
Quindi, con questo, completiamo l'aggiornamento al nostro server qui.

822
01:07:11,480 --> 01:07:15,040
Quindi, con questo, abbiamo aggiornato tutto sul lato server.

823
01:07:15,040 --> 01:07:17,890
Quindi, salviamo tutte le modifiche sul lato server.

824
01:07:17,890 --> 01:07:26,755
Così ora, il nostro server è pronto a gestire le richieste in arrivo dal nostro client React.

825
01:07:26,755 --> 01:07:29,340
Con questo, completiamo questo esercizio.

826
01:07:29,340 --> 01:07:33,300
In questo esercizio, abbiamo ora preparato il nostro server espresso

827
01:07:33,300 --> 01:07:38,985
per gestire le richieste in arrivo dal nostro client React.

828
01:07:38,985 --> 01:07:43,190
Nel prossimo esercizio, andremo a esaminare il client reagire in modo più dettagliato per

829
01:07:43,190 --> 01:07:48,000
capire come sta comunicando con questo server aggiuntivo.

830
01:07:48,000 --> 01:07:50,640
Questo è un buon momento per fare

831
01:07:50,640 --> 01:07:55,880
una copertura git con il messaggio che integra client e server.