1
00:00:03,710 --> 00:00:07,605
Ora che abbiamo imparato a conoscere la popolazione mangusta,

2
00:00:07,605 --> 00:00:14,040
e come ci permette di popolare un documento con informazioni da un altro documento.

3
00:00:14,040 --> 00:00:20,605
In questo esercizio, modificheremo il server espresso su cui abbiamo lavorato finora.

4
00:00:20,605 --> 00:00:25,580
Nello schema piatto che abbiamo definito in precedenza, abbiamo avuto commenti.

5
00:00:25,580 --> 00:00:28,365
Per i commenti, abbiamo avuto il campo autore

6
00:00:28,365 --> 00:00:31,490
che usiamo per memorizzare i dettagli sull'autore.

7
00:00:31,490 --> 00:00:40,815
In questo esercizio, trasformeremo il campo autore in un riferimento a un documento utente,

8
00:00:40,815 --> 00:00:46,265
e useremo popolazione Mangusta per popolare le informazioni nel

9
00:00:46,265 --> 00:00:50,330
documento piatti come e quando richiesto

10
00:00:50,330 --> 00:00:54,440
al fine di fornire le informazioni al cliente.

11
00:00:54,440 --> 00:00:59,960
Ora l'uso della popolazione popolata e mangusta dovrebbe essere fatto

12
00:00:59,960 --> 00:01:05,550
in modo giudizioso in modo da non causare troppo sovraccarico sul lato server.

13
00:01:05,550 --> 00:01:06,890
Ora, in questo esercizio,

14
00:01:06,890 --> 00:01:09,395
lo useremo semplicemente per popolare le informazioni

15
00:01:09,395 --> 00:01:13,280
nel campo autore dei nostri commenti.

16
00:01:13,280 --> 00:01:18,660
Quindi, procediamo con l'esercizio per imparare come usiamo la popolazione Mangusta.

17
00:01:18,660 --> 00:01:21,455
Per iniziare a questo esercizio,

18
00:01:21,455 --> 00:01:25,315
vai al progetto e apri il file user.js.

19
00:01:25,315 --> 00:01:27,730
Quindi, nel file user.js,

20
00:01:27,730 --> 00:01:29,600
memorizziamo lo schema utente.

21
00:01:29,600 --> 00:01:35,515
Ho intenzione di modificare lo schema utente aggiungendo un paio di campi in più.

22
00:01:35,515 --> 00:01:38,220
Uno è il primo nome,

23
00:01:38,220 --> 00:01:40,070
che sarà

24
00:01:40,070 --> 00:01:48,115
della stringa di tipo e

25
00:01:48,115 --> 00:01:52,025
l'impostazione predefinita sarebbe una stringa vuota.

26
00:01:52,025 --> 00:01:56,555
Quindi, il nome come suggerisce il nome,

27
00:01:56,555 --> 00:02:03,630
memorizza il nome per l'utente e poi avremo un altro campo chiamato cognome,

28
00:02:03,630 --> 00:02:06,540
che è anche dello stesso tipo.

29
00:02:06,540 --> 00:02:13,540
Quindi, sto solo andando a copiare questi due pezzi di informazioni e poi copiare

30
00:02:13,540 --> 00:02:20,735
qui e così ora il nostro documento utente conterrà,

31
00:02:20,735 --> 00:02:22,840
oltre al nome utente e password,

32
00:02:22,840 --> 00:02:26,760
nome utente e silenzio e sale che abbiamo visto in precedenza,

33
00:02:26,760 --> 00:02:34,450
che viene automaticamente aggiunto dal modulo Mangusta locale passaporto .

34
00:02:34,450 --> 00:02:39,840
Avremo anche il nome e il cognome per l'utente che viene definito qui.

35
00:02:39,840 --> 00:02:43,505
Più tardi vedremo come inizializzare

36
00:02:43,505 --> 00:02:50,765
questi valori modificando il processo di registrazione dell'utente.

37
00:02:50,765 --> 00:02:52,950
Ora, una volta completato questo,

38
00:02:52,950 --> 00:02:56,599
quindi in questo modo le informazioni dell'utente

39
00:02:56,599 --> 00:03:00,880
possono essere semplicemente recuperate cercando il documento utente qui.

40
00:03:00,880 --> 00:03:05,200
Quindi, ora che abbiamo le informazioni sull'utente nel documento utente,

41
00:03:05,200 --> 00:03:08,560
andando nello schema piatto,

42
00:03:08,560 --> 00:03:11,015
quindi andando nel file dishes.js.

43
00:03:11,015 --> 00:03:13,260
Nello schema del piatto in precedenza,

44
00:03:13,260 --> 00:03:18,465
stavamo memorizzando l'autore del documento sotto forma di una stringa qui.

45
00:03:18,465 --> 00:03:22,700
Ora stiamo per approfittare del fatto che

46
00:03:22,700 --> 00:03:27,425
abbiamo il sostegno della popolazione di mangusta.

47
00:03:27,425 --> 00:03:33,740
Quindi ho intenzione di trasformare il campo di commento da una stringa in

48
00:03:33,740 --> 00:03:41,975
ID oggetto tipi di schema mangusta.

49
00:03:41,975 --> 00:03:49,120
Quindi, da questa parte, scusa, campo sbagliato.

50
00:03:49,120 --> 00:03:53,135
Volevo trasformare il campo dell'autore in

51
00:03:53,135 --> 00:04:02,295
ID oggetto tipi di schema mangusta.

52
00:04:02,295 --> 00:04:05,390
Quindi, il campo autore ora invece di memorizzare una stringa,

53
00:04:05,390 --> 00:04:10,835
avrà un riferimento al documento utente.

54
00:04:10,835 --> 00:04:14,105
Quindi, quando trasformo il campo autore in questo tipo,

55
00:04:14,105 --> 00:04:20,180
la seconda proprietà che ho definito qui sarà un riferimento,

56
00:04:20,180 --> 00:04:25,229
che sarebbe un riferimento al modello utente.

57
00:04:25,229 --> 00:04:27,980
Quindi, in questo modo, stiamo per

58
00:04:27,980 --> 00:04:31,370
collegare questo campo autore e questo campo autore

59
00:04:31,370 --> 00:04:37,585
semplicemente memorizzerà un riferimento all'ID del documento utente,

60
00:04:37,585 --> 00:04:43,790
invece di memorizzare i dettagli sull'autore sotto forma di un nome.

61
00:04:43,790 --> 00:04:45,100
Ora, quando lo facciamo,

62
00:04:45,100 --> 00:04:48,350
possiamo usare mangusta popolare per popolare

63
00:04:48,350 --> 00:04:53,115
queste informazioni nel nostro documento piatti ogni volta che richiesto.

64
00:04:53,115 --> 00:04:58,595
Quindi, con questa modifica allo schema dei piatti, nel file dishes.js,

65
00:04:58,595 --> 00:05:05,910
aggiorneremo il router piatto per utilizzare la popolazione di mangusta.

66
00:05:05,910 --> 00:05:09,030
Quindi, andando a dishRouter.js.

67
00:05:09,030 --> 00:05:16,120
Nel router piatto, ricordare che quando stavamo ottenendo un piatto qui,

68
00:05:16,120 --> 00:05:19,470
ora quando si ottiene il piatto qui,

69
00:05:19,470 --> 00:05:23,820
diciamo piatti trovare poi.

70
00:05:23,820 --> 00:05:26,610
Quindi, proprio a quel punto,

71
00:05:26,610 --> 00:05:36,005
diremo piatti trovare e diremo dopo questo, popolare.

72
00:05:36,005 --> 00:05:41,924
Quindi, stiamo usando il supporto della popolazione in mangusta

73
00:05:41,924 --> 00:05:48,165
e diremo popolare commenti autore.

74
00:05:48,165 --> 00:05:49,740
Quindi, affermando questo,

75
00:05:49,740 --> 00:05:51,060
stiamo dicendo che quando

76
00:05:51,060 --> 00:05:58,750
il documento piatti è stato costruito per inviare la risposta all'utente,

77
00:05:58,750 --> 00:06:05,810
stiamo andando a popolare il campo autore dentro lì dal documento utente in là.

78
00:06:05,810 --> 00:06:09,095
Quindi, questa chiamata al popolato garantirà che

79
00:06:09,095 --> 00:06:14,665
l'altro campo verrà popolato con le informazioni come richiesto.

80
00:06:14,665 --> 00:06:18,565
Allo stesso modo, andando all'ID piatto qui,

81
00:06:18,565 --> 00:06:21,660
anche nell'ID piatto, stessa cosa.

82
00:06:21,660 --> 00:06:31,680
Diciamo popolare e commenti autore aggiunto

83
00:06:31,680 --> 00:06:37,320
nei piatti trovare per id

84
00:06:37,320 --> 00:06:43,395
nel get dell'endpoint /dish ID.

85
00:06:43,395 --> 00:06:54,350
Allo stesso modo, nei commenti anche quando

86
00:06:54,520 --> 00:07:02,370
recuperiamo il piatto, diremo popolare commenti autore qui e la

87
00:07:02,370 --> 00:07:09,900
stessa cosa anche nel router piatto,

88
00:07:09,900 --> 00:07:13,695
commenti ID piatto, commento ID anche.

89
00:07:13,695 --> 00:07:16,530
Più grande popolano queste informazioni lì.

90
00:07:16,530 --> 00:07:22,620
Ora, naturalmente, ciò che significa è che quando pubblichi il piatto,

91
00:07:22,620 --> 00:07:30,090
prima stai includendo le informazioni dell'autore nel corpo del messaggio.

92
00:07:30,090 --> 00:07:35,120
Quindi, ora qui quando proviamo a spingere il commento in questo,

93
00:07:35,120 --> 00:07:41,370
quindi questo post corrisponde al campo commenti ID piatto.

94
00:07:41,370 --> 00:07:46,280
Quindi, questo è il modo in cui stavamo postando un commento su un piatto specifico.

95
00:07:46,280 --> 00:07:48,570
Quindi, ora in questo post,

96
00:07:48,570 --> 00:07:53,890
dal momento che non stiamo memorizzando le informazioni sull'autore più,

97
00:07:53,890 --> 00:08:02,400
quindi quello che dobbiamo fare è quando spingiamo l'elemento nel campo dell'autore lì.

98
00:08:02,400 --> 00:08:06,720
Quindi, qui quando stai popolando le informazioni nel piatto,

99
00:08:06,720 --> 00:08:10,680
dovremo prima-

100
00:08:12,010 --> 00:08:16,430
Ricordiamo che il corpo contiene già il commento,

101
00:08:16,430 --> 00:08:21,505
ma la proprietà dell'autore non sarà lì nel corpo del messaggio nel libro,

102
00:08:21,505 --> 00:08:26,020
ma a seconda di quale utente sta postando queste informazioni,

103
00:08:26,020 --> 00:08:29,250
possiamo popolare immediatamente il campo autore.

104
00:08:29,250 --> 00:08:32,535
Ora, come facciamo a sapere quale utente sta pubblicando queste informazioni?

105
00:08:32,535 --> 00:08:38,165
Il fatto che abbiamo fatto l'utente di verifica qui per il post,

106
00:08:38,165 --> 00:08:42,115
significa che un utente specifico sta pubblicando queste informazioni,

107
00:08:42,115 --> 00:08:44,250
e facendo l'utente di verifica,

108
00:08:44,250 --> 00:08:50,415
avremmo già caricato nel req.user nell'oggetto richiesta.

109
00:08:50,415 --> 00:08:51,925
Nell' oggetto richiesta,

110
00:08:51,925 --> 00:08:55,565
possiamo entrare e dire utente relitto,

111
00:08:55,565 --> 00:08:59,010
e quindi sottolineatura ID qui.

112
00:08:59,010 --> 00:09:01,910
Permettetemi ancora una volta di ribadire questo punto:

113
00:09:01,910 --> 00:09:05,760
come otteniamo qui le informazioni dell'autore?

114
00:09:05,760 --> 00:09:10,470
Ora, ricorda che abbiamo aggiornato lo schema dei piatti, in

115
00:09:10,470 --> 00:09:13,875
modo che il campo autore nel commento memorizzi semplicemente

116
00:09:13,875 --> 00:09:20,915
l'ID oggetto riferito all'utente che sta postando questo commento.

117
00:09:20,915 --> 00:09:24,450
Ora, come facciamo a sapere quale utente sta postando questo commento?

118
00:09:24,450 --> 00:09:27,085
Ora di nuovo, per ribadire questo punto,

119
00:09:27,085 --> 00:09:31,825
ricordare che quando abbiamo verificato l'utente qui chiamando autenticazione verifica utente,

120
00:09:31,825 --> 00:09:37,590
il passaporto autorizzato JWT avrebbe caricato

121
00:09:37,590 --> 00:09:45,120
le informazioni utente nel corpo della richiesta sotto forma di req.user.

122
00:09:45,120 --> 00:09:48,470
Quindi, quell'utente conterrà l'ID

123
00:09:48,470 --> 00:09:52,520
dell'utente specifico che sta effettivamente postando questo commento.

124
00:09:52,520 --> 00:09:55,730
Quindi, abbiamo già verificato l'autenticità dell'utente,

125
00:09:55,730 --> 00:10:01,400
e quindi l'ID utente può semplicemente essere ottenuto dicendo req.user.

126
00:10:01,400 --> 00:10:04,400
_ID, e l'ID di quell'utente,

127
00:10:04,400 --> 00:10:09,380
assegnerò questo al campo dell'autore fuori dal commento.

128
00:10:09,380 --> 00:10:10,990
Ora, quando il commento arriva,

129
00:10:10,990 --> 00:10:13,880
il commento nel corpo del messaggio di richiesta

130
00:10:13,880 --> 00:10:17,355
conterrà solo il campo di valutazione e il campo commento.

131
00:10:17,355 --> 00:10:23,425
Ora non vogliamo inviare esplicitamente il campo autore più dal lato client,

132
00:10:23,425 --> 00:10:26,090
invece che dovrebbe essere inserito automaticamente

133
00:10:26,090 --> 00:10:28,990
sul lato server in base all'autenticità

134
00:10:28,990 --> 00:10:32,180
dell'utente Questo è il punto che avevo

135
00:10:32,180 --> 00:10:36,830
ribadito in questa modifica che ho fatto qui.

136
00:10:36,830 --> 00:10:43,400
Pertanto, le informazioni degli utenti vengono ottenute automaticamente dal req.user che viene

137
00:10:43,400 --> 00:10:50,200
caricato nel corpo del messaggio di richiesta dall'utente di verifica dell'autenticazione,

138
00:10:50,200 --> 00:10:55,250
che utilizzerà l'autenticazione Passport con la strategia JWT lì.

139
00:10:55,250 --> 00:10:59,795
Inoltre, ora quando riceviamo il piatto aggiornato qui,

140
00:10:59,795 --> 00:11:03,695
dobbiamo popolare le informazioni dell'autore nel piatto.

141
00:11:03,695 --> 00:11:05,500
Quindi, a questo punto,

142
00:11:05,500 --> 00:11:08,675
quando riceviamo il piatto qui,

143
00:11:08,675 --> 00:11:15,370
andremo a cercare i piatti qui.

144
00:11:15,370 --> 00:11:20,150
Quindi, diremo piatti.FindById

145
00:11:21,000 --> 00:11:28,090
e quindi fornire l'ID piatto come parametro qui,

146
00:11:28,090 --> 00:11:30,190
quindi diremo trovare per ID,

147
00:11:30,190 --> 00:11:33,175
ID piatto, e poi,

148
00:11:33,175 --> 00:11:43,405
abbiamo bisogno di popolare l'autore commenti qui,

149
00:11:43,405 --> 00:11:55,600
e poi diremo poi piatto.

150
00:11:55,600 --> 00:12:04,370
Lì dentro, stiamo per inviare questa informazione piatto all'utente qui.

151
00:12:04,370 --> 00:12:07,260
Quindi, lasciami tagliare e incollarlo qui.

152
00:12:07,260 --> 00:12:12,670
Quindi, questa modifica è necessaria perché ora ho bisogno di popolare

153
00:12:12,670 --> 00:12:15,190
le informazioni dell'autore

154
00:12:15,190 --> 00:12:18,760
nel commento prima di poter inviare l'attuale all'utente.

155
00:12:18,760 --> 00:12:22,220
Quindi, questa è l'ulteriore modifica che dobbiamo

156
00:12:22,220 --> 00:12:26,105
fare quando usiamo la popolazione di Mangusta qui.

157
00:12:26,105 --> 00:12:29,950
Allo stesso modo, ora entrando nel put,

158
00:12:29,950 --> 00:12:34,450
quando modifichiamo un commento specifico con l'ID commento,

159
00:12:34,450 --> 00:12:40,830
quindi questo è sotto il piatto ID commenti commento parte ID.

160
00:12:40,830 --> 00:12:42,890
Quindi, quando facciamo il put qui,

161
00:12:42,890 --> 00:12:49,230
quindi prima troviamo i piatti trovare da id req params dish ID,

162
00:12:49,230 --> 00:12:50,840
poi nel piatto.

163
00:12:50,840 --> 00:12:57,160
Quindi, la prima cosa che controlliamo è quello di garantire che se il piatto non è nullo,

164
00:12:57,160 --> 00:13:01,430
e il piatto commenti ID non è nullo,

165
00:13:01,430 --> 00:13:08,665
quindi abbiamo controllato per assicurarci che il commento sia effettivamente presente nel piatto,

166
00:13:08,665 --> 00:13:12,320
e poi quando il piatto stesso viene restituito,

167
00:13:12,320 --> 00:13:16,385
allora abbiamo bisogno di cercare di nuovo

168
00:13:16,385 --> 00:13:21,230
il piatto perché abbiamo bisogno di popolare l'autore dei commenti nel piatto.

169
00:13:21,230 --> 00:13:27,950
Quindi qui, diremo dishes.FindById (Dish ID),

170
00:13:31,750 --> 00:13:36,880
il motivo per cui dobbiamo fare un'altra ricerca è perché

171
00:13:36,880 --> 00:13:42,240
abbiamo bisogno di popolare i comments.author qui,

172
00:13:42,240 --> 00:13:46,355
quindi questo è l'unico motivo per cui abbiamo bisogno di fare un'altra ricerca qui.

173
00:13:46,355 --> 00:13:50,720
Poi quando riceviamo il piatto qui,

174
00:13:52,260 --> 00:13:57,700
ovviamente perché abbiamo appena aggiornato il piatto in modo che le informazioni del piatto dovrebbero essere

175
00:13:57,700 --> 00:14:03,640
trovate nel database, in

176
00:14:03,640 --> 00:14:07,490
modo che dovrebbe funzionare bene e poi all'interno ci dirà

177
00:14:07,490 --> 00:14:12,215
codice di stato del rischio 200 res set header content type application json,

178
00:14:12,215 --> 00:14:14,960
e poi restituire il piatto qui,

179
00:14:14,960 --> 00:14:16,740
e poi gestiremo l'errore qui,

180
00:14:16,740 --> 00:14:19,630
e poi gli altri se i piatti

181
00:14:19,630 --> 00:14:24,095
ora e anche gli altri errori che abbiamo impostato in precedenza,

182
00:14:24,095 --> 00:14:27,050
saranno gestiti come al solito qui.

183
00:14:27,050 --> 00:14:32,790
Quindi, queste sono le modifiche aggiuntive che dobbiamo assicurarci quando aggiorni il piatto,

184
00:14:32,790 --> 00:14:39,175
quando stai inviando il commento aggiornato o il piatto aggiornato,

185
00:14:39,175 --> 00:14:44,485
allora popoleremo il commento nel piatto qui.

186
00:14:44,485 --> 00:14:48,160
Allo stesso modo, andando alla cancellazione qui,

187
00:14:48,160 --> 00:14:50,575
e poi dopo l'eliminazione del commento, di

188
00:14:50,575 --> 00:14:59,310
nuovo stiamo andando a recuperare il piatto e popolare le informazioni dell'autore.

189
00:14:59,310 --> 00:15:01,275
Quindi, lasciami solo copiare questa parte,

190
00:15:01,275 --> 00:15:04,130
e poi faremo esattamente la stessa cosa qui,

191
00:15:04,130 --> 00:15:06,770
quindi diremo piatto salvare,

192
00:15:06,770 --> 00:15:16,210
poi stiamo andando a controllare dish.FindByid (autore piatto),

193
00:15:16,210 --> 00:15:19,760
e poi popoleremo l'autore commenti,

194
00:15:19,760 --> 00:15:21,925
e poi diremo (poi) piatto,

195
00:15:21,925 --> 00:15:24,920
e poi res.StatusCode, e così via,

196
00:15:24,920 --> 00:15:29,350
e la gestione degli errori rimanente proprio come prima qui.

197
00:15:29,350 --> 00:15:33,040
Quindi, con questa modifica al router piatto,

198
00:15:33,040 --> 00:15:41,420
ora l'ultimo punto che dobbiamo considerare è il fatto che nel file user.js,

199
00:15:41,420 --> 00:15:43,740
ora abbiamo aggiunto nei campi,

200
00:15:43,740 --> 00:15:49,050
il nome e il cognome campo che per impostazione predefinita saranno stringhe vuote.

201
00:15:49,050 --> 00:15:51,880
Quindi, quando l'utente si sta registrando,

202
00:15:51,880 --> 00:15:54,670
dovremmo consentire all'utente di fornire il nome e

203
00:15:54,670 --> 00:15:58,040
il cognome nel processo di registrazione.

204
00:15:58,040 --> 00:16:00,040
Ora, dove si svolge?

205
00:16:00,040 --> 00:16:03,025
Questo si svolge nel file.js dell'utente.

206
00:16:03,025 --> 00:16:05,390
Quindi, andando agli utenti users.js,

207
00:16:05,390 --> 00:16:09,885
quando l'utente pubblica la registrazione barra, in

208
00:16:09,885 --> 00:16:13,050
precedenza stavamo solo postando il nome utente e la password.

209
00:16:13,050 --> 00:16:15,105
Oltre a questi due,

210
00:16:15,105 --> 00:16:21,785
nell'oggetto json che includiamo nel corpo del messaggio di richiesta in arrivo,

211
00:16:21,785 --> 00:16:25,530
il messaggio di richiesta post che arriva dal lato client,

212
00:16:25,530 --> 00:16:29,590
possiamo anche includere il nome e il cognome per l'utente.

213
00:16:29,590 --> 00:16:33,740
Quindi, quando il nome e il cognome per l'utente sono inclusi,

214
00:16:33,740 --> 00:16:35,590
quindi cosa ho intenzione di fare qui?

215
00:16:35,590 --> 00:16:42,450
Quindi, ricorda che quando dici user.register a questo punto entrano le informazioni dell'utente,

216
00:16:42,450 --> 00:16:45,785
e poi hai inviato il nome utente qui,

217
00:16:45,785 --> 00:16:49,460
e hai anche assegnato la password qui che verrà

218
00:16:49,460 --> 00:16:53,380
trasformata in hash e sale dalla mangusta locale del passaporto.

219
00:16:53,380 --> 00:17:00,000
Ora, se non ci sono errori, significa che la registrazione dell'utente ha avuto successo,

220
00:17:00,000 --> 00:17:08,740
e quindi a questo punto quello che faremo è diremo se req.body.

221
00:17:08,740 --> 00:17:13,420
Nome. Quindi, il che significa che il corpo del messaggio di richiesta in arrivo,

222
00:17:13,420 --> 00:17:16,345
se contiene il nome,

223
00:17:16,345 --> 00:17:24,770
allora diremo user.firstname è uguale a req.body.firstname.

224
00:17:26,160 --> 00:17:29,675
Allo stesso modo, anche per il cognome.

225
00:17:29,675 --> 00:17:32,040
Quindi, a questo punto,

226
00:17:32,040 --> 00:17:34,780
avremmo l'utente disponibile qui.

227
00:17:34,780 --> 00:17:40,125
Vedi che l'utente sta arrivando come secondo parametro a questa funzione di callback qui.

228
00:17:40,125 --> 00:17:43,455
Quindi, stiamo impostando il nome cambiando

229
00:17:43,455 --> 00:17:51,490
la proprietà nome all'interno del documento utente qui dicendo, req.body.firstname.

230
00:17:51,490 --> 00:17:55,395
Se esiste, allora imposteremo il nome dell'utente su quello.

231
00:17:55,395 --> 00:18:03,220
Allo stesso modo, se il nome req.body.last è disponibile,

232
00:18:03,220 --> 00:18:09,630
quindi aggiorneremo anche il cognome dell'utente come req.body.lastname.

233
00:18:09,770 --> 00:18:16,650
E una volta che abbiamo fatto queste due modifiche al nome e al cognome,

234
00:18:16,650 --> 00:18:23,160
allora abbiamo bisogno di salvare la modifica che abbiamo fatto all'utente.

235
00:18:23,160 --> 00:18:25,030
Quindi, abbiamo appena aggiornato l'utente.

236
00:18:25,030 --> 00:18:30,550
Quindi, diremo user.save quindi questo

237
00:18:30,550 --> 00:18:37,190
restituirà l'errore o l'utente.

238
00:18:37,190 --> 00:18:41,025
Quindi, se la modifica è stata salvata correttamente,

239
00:18:41,025 --> 00:18:43,765
restituirà l'errore,

240
00:18:43,765 --> 00:18:49,380
altrimenti restituirà il valore dell'utente e questo passaporto autenticato

241
00:18:49,380 --> 00:18:55,710
lo faremo all'interno di questo utente qui.

242
00:18:55,710 --> 00:19:00,505
Quindi, diremo, user.save (err, utente).

243
00:19:00,505 --> 00:19:04,740
E poi anche dobbiamo controllare incrociando per assicurarci che

244
00:19:04,740 --> 00:19:10,660
se c'è un errore nel salvare le modifiche all'utente,

245
00:19:10,660 --> 00:19:15,180
allora diremo res status code 500,

246
00:19:15,180 --> 00:19:18,485
quindi lasciami copiare questo da lì.

247
00:19:18,485 --> 00:19:23,275
Quindi, diremo codice di stato res 500,

248
00:19:23,275 --> 00:19:30,220
res set intestazione tipo di contenuto applicazione json e res.jason qui.

249
00:19:30,220 --> 00:19:35,995
Poi, e torneremo a questo punto.

250
00:19:35,995 --> 00:19:37,960
Se non ci sono errori,

251
00:19:37,960 --> 00:19:40,480
ovviamente si autentica l'utente chiamando

252
00:19:40,480 --> 00:19:43,550
l'autenticazione passaporto con il locale per assicurarsi che

253
00:19:43,550 --> 00:19:48,835
la registrazione dell'utente abbia avuto successo e questo dovrebbe essere

254
00:19:48,835 --> 00:19:56,390
fatto correttamente e quando in tal caso si restituirà questo messaggio al lato client.

255
00:19:56,390 --> 00:20:03,215
Dobbiamo chiudere questo user.save qui.

256
00:20:03,215 --> 00:20:07,520
Quindi, assicurarsi di chiudere correttamente questo endpoint.

257
00:20:07,520 --> 00:20:11,005
Quindi, user.save è chiuso qui, e basta.

258
00:20:11,005 --> 00:20:14,730
Queste sono le modifiche che dobbiamo apportare all'utente.

259
00:20:14,730 --> 00:20:21,740
Quindi, dopo che l'utente è registrato con il nome utente specificato e la password data,

260
00:20:21,740 --> 00:20:24,940
quindi dopo che l'utente è stato registrato con successo,

261
00:20:24,940 --> 00:20:28,235
allora imposteremo il nome e

262
00:20:28,235 --> 00:20:32,925
il cognome campo del documento utente utilizzando questi due qui.

263
00:20:32,925 --> 00:20:35,900
Vogliamo assicurarci che l'utente sia

264
00:20:35,900 --> 00:20:39,160
registrato correttamente prima di inviare il nome e il cognome per questo.

265
00:20:39,160 --> 00:20:42,540
Quindi, ecco perché stiamo eseguendo questa operazione dopo che l'utente

266
00:20:42,540 --> 00:20:46,360
è stato registrato con successo. Questo è tutto.

267
00:20:46,360 --> 00:20:53,785
Salviamo le modifiche e andiamo a controllare il server.

268
00:20:53,785 --> 00:20:56,185
Dopo aver salvato le modifiche,

269
00:20:56,185 --> 00:20:59,980
andiamo ora al terminale e

270
00:20:59,980 --> 00:21:06,925
poi prima di avviare il server,

271
00:21:06,925 --> 00:21:16,690
lasciami prima controllare il mio MongoDB ed eliminare l'utente che abbiamo registrato in precedenza.

272
00:21:16,690 --> 00:21:25,640
Quindi, diremo usa confusione e poi diremo db.usersfind.

273
00:21:25,650 --> 00:21:30,690
Quindi, sappiamo che questo particolare utente è stato registrato in precedenza,

274
00:21:30,690 --> 00:21:32,580
ma quando registriamo quell'utente,

275
00:21:32,580 --> 00:21:35,700
non abbiamo registrato il nome e il cognome per l'utente.

276
00:21:35,700 --> 00:21:39,155
Quindi, ho intenzione di eliminare questo utente e quindi ri-registrare l'utente.

277
00:21:39,155 --> 00:21:48,370
Quindi, per farlo usando l'ondulazione Mongo, dirò che gli utenti db cadono,

278
00:21:48,370 --> 00:21:52,220
e poi diremo

279
00:21:52,220 --> 00:21:54,620
che gli utenti db trovano, e questo dovrebbe restituire un vuoto.

280
00:21:54,620 --> 00:22:01,685
Nessun utente registrato lì e poi usciremo dall'ondulazione Mongo.

281
00:22:01,685 --> 00:22:05,285
E così, una volta rimosso quell'utente registrato,

282
00:22:05,285 --> 00:22:08,760
allora, lasciami avviare il mio server.

283
00:22:09,490 --> 00:22:12,275
E una volta che il server è attivo e funzionante,

284
00:22:12,275 --> 00:22:16,240
andiamo a Postman e poi registrare

285
00:22:16,240 --> 00:22:20,930
un nuovo utente insieme al nome e cognome dell'utente.

286
00:22:20,930 --> 00:22:26,845
Poi, si accederanno come tale utente e poi vedremo come

287
00:22:26,845 --> 00:22:31,650
la popolazione Mangusta ci aiuta a popolare

288
00:22:31,650 --> 00:22:37,000
automaticamente le informazioni sull'utente nel documento lì.

289
00:22:37,000 --> 00:22:40,029
Ora andando a Postman,

290
00:22:40,029 --> 00:22:42,660
lasciami fare un segno di un nuovo utente.

291
00:22:42,660 --> 00:22:48,310
Quindi, sto facendo un post localhost: 3000 utenti si iscrivono.

292
00:22:48,310 --> 00:22:50,715
Nel corpo del messaggio,

293
00:22:50,715 --> 00:22:54,910
avevamo già il nome utente e la password.

294
00:22:54,910 --> 00:22:59,199
Permettetemi di aggiungere due campi aggiuntivi:

295
00:22:59,199 --> 00:23:09,350
nome, cognome.

296
00:23:14,880 --> 00:23:18,530
Quindi, registrare l'utente.

297
00:23:20,850 --> 00:23:23,680
Quindi, una volta registrato l'utente,

298
00:23:23,680 --> 00:23:26,350
puoi vedere che la registrazione ha avuto successo.

299
00:23:26,350 --> 00:23:29,810
Ora, lasciami accedere come questo utente.

300
00:23:29,820 --> 00:23:32,640
Quindi, per accedere come utente,

301
00:23:32,640 --> 00:23:37,620
lasciami fare un post e controllo incrociato per assicurarmene.

302
00:23:37,620 --> 00:23:40,475
Quindi, sto facendo un post per accedere agli utenti.

303
00:23:40,475 --> 00:23:45,725
Lasciami controllare e vedo che il nome utente e la password sono digitati correttamente lì.

304
00:23:45,725 --> 00:23:47,775
Quindi, quando

305
00:23:47,775 --> 00:23:53,165
accedo, dovrei essere connesso con successo e dovrei essere in grado di ottenere questo token lì.

306
00:23:53,165 --> 00:24:02,660
Perché questo token è essenziale per noi per essere in grado di aggiungere un piatto al nostro sito server.

307
00:24:02,660 --> 00:24:05,915
Quindi, dopo aver ottenuto il token,

308
00:24:05,915 --> 00:24:10,250
copia questa stringa di token e salvala perché ne avrai bisogno

309
00:24:10,250 --> 00:24:13,220
nell'intestazione di autorizzazione per le

310
00:24:13,220 --> 00:24:16,910
operazioni post put ed delete che eseguirai in seguito.

311
00:24:16,910 --> 00:24:20,540
Quindi fammi copiare quel gettone.

312
00:24:20,540 --> 00:24:23,890
Ora, normalmente il modo in cui tengo questi token è,

313
00:24:23,890 --> 00:24:28,400
che aprirò un documento di testo e poi lo copierò e incollerò nel documento di testo.

314
00:24:28,400 --> 00:24:31,190
In modo che per le successive richieste di postino,

315
00:24:31,190 --> 00:24:34,230
posso semplicemente copiare questa stringa e quindi incollarla

316
00:24:34,230 --> 00:24:37,770
nell'intestazione di autorizzazione, se necessario.

317
00:24:37,770 --> 00:24:44,070
Quindi, lasciami copiare quel token e qui ho un documento di testo aperto qui.

318
00:24:44,070 --> 00:24:50,815
Quindi, ho intenzione di incollare quella stringa in questo documento di testo.

319
00:24:50,815 --> 00:24:57,170
Quindi, qui abbiamo il token che abbiamo ottenuto.

320
00:24:57,170 --> 00:25:03,120
Ora andiamo a postare un piatto al nostro server.

321
00:25:03,120 --> 00:25:05,135
Tornando al postino,

322
00:25:05,135 --> 00:25:07,535
fammi postare un piatto al server.

323
00:25:07,535 --> 00:25:12,690
Quindi, questo è dove sceglierò il post qui.

324
00:25:12,690 --> 00:25:21,334
Qui dentro, ho le informazioni del piatto che avevo usato in precedenza, ma per i commenti,

325
00:25:21,334 --> 00:25:25,345
ora, ricordare che in precedenza avevamo il campo autore che stava memorizzando una stringa.

326
00:25:25,345 --> 00:25:28,770
Quindi, tutti questi commenti non sono validi.

327
00:25:28,770 --> 00:25:35,110
Quindi, ho intenzione di eliminare tutti questi commenti dalla presentazione perché,

328
00:25:35,110 --> 00:25:42,570
ora, ci aspettiamo che l'utente pubblichi commenti da solo.

329
00:25:42,570 --> 00:25:44,460
Quando l'utente pubblica commenti,

330
00:25:44,460 --> 00:25:52,155
aggiungeremo automaticamente l'ID dell'utente nel campo autore dei commenti.

331
00:25:52,155 --> 00:25:55,390
Quindi, lasciami postare questo piatto qui.

332
00:25:55,390 --> 00:25:57,325
Andando all'intestazione,

333
00:25:57,325 --> 00:26:01,550
nell'intestazione di autorizzazione, ho intenzione di dire,

334
00:26:02,310 --> 00:26:12,785
portatore e poi, incollare il token e quindi inviare.

335
00:26:12,785 --> 00:26:17,055
Dovrei fare un post su quello.

336
00:26:17,055 --> 00:26:21,950
Quindi, dirò post e così quando posto ora,

337
00:26:21,950 --> 00:26:26,785
si vede che questo piatto è stato pubblicato sul lato server,

338
00:26:26,785 --> 00:26:31,340
e con l'array di commenti è vuoto in questo momento.

339
00:26:31,340 --> 00:26:34,450
Quindi, dopo aver postato questo piatto,

340
00:26:34,450 --> 00:26:37,660
fammi copiare l'ID di questo piatto.

341
00:26:37,660 --> 00:26:40,835
Quindi, lasciami copiare questo ID per il piatto perché ne avrò

342
00:26:40,835 --> 00:26:44,735
bisogno per postare commenti per questo piatto.

343
00:26:44,735 --> 00:26:47,075
Poi, andando dal mio editor di testo,

344
00:26:47,075 --> 00:26:51,485
ho intenzione di salvare l'ID del piatto qui.

345
00:26:51,485 --> 00:26:54,550
Ora, naturalmente, una volta creato il lato client,

346
00:26:54,550 --> 00:26:57,770
il cliente avrà automaticamente tutte queste informazioni.

347
00:26:57,770 --> 00:27:02,565
Quindi, il tuo client sarà automaticamente in grado di inviare il token e così via.

348
00:27:02,565 --> 00:27:06,385
Quindi, non è necessario fare questa cosa taglia-incolla, ma con il postino,

349
00:27:06,385 --> 00:27:11,750
questo è l'unico modo in cui possiamo aggiungere qualsiasi informazione alle nostre richieste di postino,

350
00:27:11,750 --> 00:27:17,185
che vanno dal postino al server.

351
00:27:17,185 --> 00:27:22,090
Ora, al fine di convincerci che questo piatto esiste in realtà,

352
00:27:22,090 --> 00:27:26,310
lasciami fare un get sul locale hostcolon:3000/piatti.

353
00:27:26,570 --> 00:27:30,750
Quando faccio un get, si può effettivamente vedere che

354
00:27:30,750 --> 00:27:34,175
questo particolare piatto esiste sul lato server.

355
00:27:34,175 --> 00:27:37,600
Quindi, proviamo ora a postare un commento.

356
00:27:37,600 --> 00:27:39,515
Quindi, per pubblicare un commento,

357
00:27:39,515 --> 00:27:45,550
facciamo un post e diremo,

358
00:27:49,940 --> 00:27:54,950
localhost: 3000/piatti, barra e l'ID del piatto che

359
00:27:54,950 --> 00:27:59,910
ho appena copiato, e barra commenti.

360
00:27:59,910 --> 00:28:03,090
Quando pubblichi sui commenti,

361
00:28:03,090 --> 00:28:11,285
devi assicurarti che nel corpo aggiungeremo il commento qui.

362
00:28:11,285 --> 00:28:13,605
Quindi, un commento tipico contiene

363
00:28:13,605 --> 00:28:20,555
una valutazione di dire

364
00:28:20,555 --> 00:28:26,140
cinque e poi commento.

365
00:28:29,030 --> 00:28:33,535
Quindi, lasciami digitare qualche commento casuale,

366
00:28:33,535 --> 00:28:34,915
solo per dimostrarti.

367
00:28:34,915 --> 00:28:41,085
Quindi, questo dovrebbe essere nel corpo del post per i commenti e nell'intestazione,

368
00:28:41,085 --> 00:28:44,665
dovremmo aggiungere l'intestazione di autorizzazione.

369
00:28:44,665 --> 00:28:50,525
Quindi, per l'intestazione di autorizzazione, diremo, portatore.

370
00:28:50,525 --> 00:28:54,875
Devo incollare il token qui,

371
00:28:54,875 --> 00:28:59,065
incollando il valore del token che ho salvato in precedenza.

372
00:28:59,065 --> 00:29:02,575
Vediamo ora pubblicare questo commento.

373
00:29:02,575 --> 00:29:05,265
Quindi, quando il commento viene pubblicato,

374
00:29:05,265 --> 00:29:07,705
diamo un'occhiata al valore restituito qui.

375
00:29:07,705 --> 00:29:09,510
Quindi, mentre navighi verso il basso,

376
00:29:09,510 --> 00:29:14,975
puoi vedere che il piatto a cui è stato aggiunto il commento, è stato restituito.

377
00:29:14,975 --> 00:29:19,300
Si noti che le informazioni piatto è lì, ma nota in particolare,

378
00:29:19,300 --> 00:29:22,620
ciò che è contenuto nel commento che è stato pubblicato qui.

379
00:29:22,620 --> 00:29:25,740
Quindi, come puoi vedere, sai già che i

380
00:29:25,740 --> 00:29:29,050
campi aggiornati e creati vengono aggiunti automaticamente da mangusta.

381
00:29:29,050 --> 00:29:31,900
La valutazione e il commento che abbiamo inviato sono

382
00:29:31,900 --> 00:29:34,780
proprio lì, ma nota come il campo autore

383
00:29:34,780 --> 00:29:40,675
ora contiene l'ID corrispondente all'utente.

384
00:29:40,675 --> 00:29:47,190
Ora, come abbiamo visto nel codice come vengono aggiunte le informazioni sul campo autore, ora,

385
00:29:47,190 --> 00:29:49,965
se si fa un get sui piatti,

386
00:29:49,965 --> 00:29:52,900
si noterà che questo campo autore verrà

387
00:29:52,900 --> 00:29:56,890
automaticamente compilato dalle informazioni degli utenti qui.

388
00:29:56,890 --> 00:30:02,180
Quindi, facciamo ora un get sul localhost: 3000/piatti.

389
00:30:02,300 --> 00:30:06,820
Così, quando ora facciamo un get su questo punto,

390
00:30:06,820 --> 00:30:12,215
ora noterete che nei piatti qui,

391
00:30:12,215 --> 00:30:15,460
proprio lì, le informazioni sul piatto è già

392
00:30:15,460 --> 00:30:20,110
presente, ma notare come il commento è ora costruito.

393
00:30:20,110 --> 00:30:23,500
Il commento ora contiene,

394
00:30:23,500 --> 00:30:27,240
i campi di commento di valutazione come abbiamo visto in precedenza,

395
00:30:27,240 --> 00:30:28,780
l'aggiornato e creato a,

396
00:30:28,780 --> 00:30:32,910
ma nota cosa è successo al campo autore qui.

397
00:30:32,910 --> 00:30:36,890
Quindi, quando si esegue una richiesta get perché abbiamo fatto un popolamento

398
00:30:36,890 --> 00:30:42,230
sul lato server quando viene richiamata l'operazione get,

399
00:30:42,230 --> 00:30:45,750
il popolamento ha automaticamente popolato

400
00:30:45,750 --> 00:30:51,390
le informazioni dell'autore in posizione nel campo autore qui.

401
00:30:51,390 --> 00:30:54,215
Quindi, lì dentro, puoi vedere che dall'autore,

402
00:30:54,215 --> 00:30:56,260
ora puoi cercare

403
00:30:56,260 --> 00:30:58,970
automaticamente il cognome e le informazioni sul nome dal campo dell'autore.

404
00:30:58,970 --> 00:31:01,645
Quindi, se hai bisogno di costruire un commento,

405
00:31:01,645 --> 00:31:04,050
ora hai la valutazione,

406
00:31:04,050 --> 00:31:08,210
il commento e anche il nome e il cognome

407
00:31:08,210 --> 00:31:12,485
dell'autore inclusi automaticamente in questo documento.

408
00:31:12,485 --> 00:31:15,645
Inoltre, il nome utente è incluso anche in questo documento.

409
00:31:15,645 --> 00:31:21,495
Quindi, questo è il modo in cui è possibile aggiungere informazioni da un altro documento e popolare

410
00:31:21,495 --> 00:31:27,905
un secondo documento con tali informazioni prima di rispondere dal sito server.

411
00:31:27,905 --> 00:31:32,315
Quindi, questo è l'uso della popolazione mangusta e come

412
00:31:32,315 --> 00:31:37,580
possiamo popolare automaticamente le informazioni in un documento mangusta.

413
00:31:37,580 --> 00:31:41,280
Con questo, completiamo questo esercizio.

414
00:31:41,280 --> 00:31:46,075
In questo esercizio, abbiamo visto l'uso della popolazione di mangusta e abbiamo anche visto

415
00:31:46,075 --> 00:31:51,785
come possiamo popolare le informazioni da un documento a un altro documento. Per

416
00:31:51,785 --> 00:31:57,340
cui, quando modifichiamo il server per fare la popolazione per le richieste,

417
00:31:57,340 --> 00:32:02,200
mangusta si prenderà automaticamente cura di popolare queste informazioni per noi.

418
00:32:02,200 --> 00:32:04,190
Tutto ciò che dobbiamo fare,

419
00:32:04,190 --> 00:32:10,900
è quello di memorizzare il riferimento all'altro documento sotto forma di ID oggetto,

420
00:32:10,900 --> 00:32:16,240
nel documento in cui si desidera popolare queste informazioni.

421
00:32:16,240 --> 00:32:18,965
Con questo, completiamo questo esercizio.

422
00:32:18,965 --> 00:32:25,230
Questo è un buon momento per fare un git-commit con il messaggio, popolazione mangusta.