Ora che abbiamo imparato a conoscere la popolazione mangusta,
e come ci permette di popolare un documento con informazioni da un altro documento.
In questo esercizio, modificheremo il server espresso su cui abbiamo lavorato finora.
Nello schema piatto che abbiamo definito in precedenza, abbiamo avuto commenti.
Per i commenti, abbiamo avuto il campo autore
che usiamo per memorizzare i dettagli sull'autore.
In questo esercizio, trasformeremo il campo autore in un riferimento a un documento utente,
e useremo popolazione Mangusta per popolare le informazioni nel
documento piatti come e quando richiesto
al fine di fornire le informazioni al cliente.
Ora l'uso della popolazione popolata e mangusta dovrebbe essere fatto
in modo giudizioso in modo da non causare troppo sovraccarico sul lato server.
Ora, in questo esercizio,
lo useremo semplicemente per popolare le informazioni
nel campo autore dei nostri commenti.
Quindi, procediamo con l'esercizio per imparare come usiamo la popolazione Mangusta.
Per iniziare a questo esercizio,
vai al progetto e apri il file user.js.
Quindi, nel file user.js,
memorizziamo lo schema utente.
Ho intenzione di modificare lo schema utente aggiungendo un paio di campi in più.
Uno è il primo nome,
che sarà
della stringa di tipo e
l'impostazione predefinita sarebbe una stringa vuota.
Quindi, il nome come suggerisce il nome,
memorizza il nome per l'utente e poi avremo un altro campo chiamato cognome,
che è anche dello stesso tipo.
Quindi, sto solo andando a copiare questi due pezzi di informazioni e poi copiare
qui e così ora il nostro documento utente conterrà,
oltre al nome utente e password,
nome utente e silenzio e sale che abbiamo visto in precedenza,
che viene automaticamente aggiunto dal modulo Mangusta locale passaporto .
Avremo anche il nome e il cognome per l'utente che viene definito qui.
Più tardi vedremo come inizializzare
questi valori modificando il processo di registrazione dell'utente.
Ora, una volta completato questo,
quindi in questo modo le informazioni dell'utente
possono essere semplicemente recuperate cercando il documento utente qui.
Quindi, ora che abbiamo le informazioni sull'utente nel documento utente,
andando nello schema piatto,
quindi andando nel file dishes.js.
Nello schema del piatto in precedenza,
stavamo memorizzando l'autore del documento sotto forma di una stringa qui.
Ora stiamo per approfittare del fatto che
abbiamo il sostegno della popolazione di mangusta.
Quindi ho intenzione di trasformare il campo di commento da una stringa in
ID oggetto tipi di schema mangusta.
Quindi, da questa parte, scusa, campo sbagliato.
Volevo trasformare il campo dell'autore in
ID oggetto tipi di schema mangusta.
Quindi, il campo autore ora invece di memorizzare una stringa,
avrà un riferimento al documento utente.
Quindi, quando trasformo il campo autore in questo tipo,
la seconda proprietà che ho definito qui sarà un riferimento,
che sarebbe un riferimento al modello utente.
Quindi, in questo modo, stiamo per
collegare questo campo autore e questo campo autore
semplicemente memorizzerà un riferimento all'ID del documento utente,
invece di memorizzare i dettagli sull'autore sotto forma di un nome.
Ora, quando lo facciamo,
possiamo usare mangusta popolare per popolare
queste informazioni nel nostro documento piatti ogni volta che richiesto.
Quindi, con questa modifica allo schema dei piatti, nel file dishes.js,
aggiorneremo il router piatto per utilizzare la popolazione di mangusta.
Quindi, andando a dishRouter.js.
Nel router piatto, ricordare che quando stavamo ottenendo un piatto qui,
ora quando si ottiene il piatto qui,
diciamo piatti trovare poi.
Quindi, proprio a quel punto,
diremo piatti trovare e diremo dopo questo, popolare.
Quindi, stiamo usando il supporto della popolazione in mangusta
e diremo popolare commenti autore.
Quindi, affermando questo,
stiamo dicendo che quando
il documento piatti è stato costruito per inviare la risposta all'utente,
stiamo andando a popolare il campo autore dentro lì dal documento utente in là.
Quindi, questa chiamata al popolato garantirà che
l'altro campo verrà popolato con le informazioni come richiesto.
Allo stesso modo, andando all'ID piatto qui,
anche nell'ID piatto, stessa cosa.
Diciamo popolare e commenti autore aggiunto
nei piatti trovare per id
nel get dell'endpoint /dish ID.
Allo stesso modo, nei commenti anche quando
recuperiamo il piatto, diremo popolare commenti autore qui e la
stessa cosa anche nel router piatto,
commenti ID piatto, commento ID anche.
Più grande popolano queste informazioni lì.
Ora, naturalmente, ciò che significa è che quando pubblichi il piatto,
prima stai includendo le informazioni dell'autore nel corpo del messaggio.
Quindi, ora qui quando proviamo a spingere il commento in questo,
quindi questo post corrisponde al campo commenti ID piatto.
Quindi, questo è il modo in cui stavamo postando un commento su un piatto specifico.
Quindi, ora in questo post,
dal momento che non stiamo memorizzando le informazioni sull'autore più,
quindi quello che dobbiamo fare è quando spingiamo l'elemento nel campo dell'autore lì.
Quindi, qui quando stai popolando le informazioni nel piatto,
dovremo prima-
Ricordiamo che il corpo contiene già il commento,
ma la proprietà dell'autore non sarà lì nel corpo del messaggio nel libro,
ma a seconda di quale utente sta postando queste informazioni,
possiamo popolare immediatamente il campo autore.
Ora, come facciamo a sapere quale utente sta pubblicando queste informazioni?
Il fatto che abbiamo fatto l'utente di verifica qui per il post,
significa che un utente specifico sta pubblicando queste informazioni,
e facendo l'utente di verifica,
avremmo già caricato nel req.user nell'oggetto richiesta.
Nell' oggetto richiesta,
possiamo entrare e dire utente relitto,
e quindi sottolineatura ID qui.
Permettetemi ancora una volta di ribadire questo punto:
come otteniamo qui le informazioni dell'autore?
Ora, ricorda che abbiamo aggiornato lo schema dei piatti, in
modo che il campo autore nel commento memorizzi semplicemente
l'ID oggetto riferito all'utente che sta postando questo commento.
Ora, come facciamo a sapere quale utente sta postando questo commento?
Ora di nuovo, per ribadire questo punto,
ricordare che quando abbiamo verificato l'utente qui chiamando autenticazione verifica utente,
il passaporto autorizzato JWT avrebbe caricato
le informazioni utente nel corpo della richiesta sotto forma di req.user.
Quindi, quell'utente conterrà l'ID
dell'utente specifico che sta effettivamente postando questo commento.
Quindi, abbiamo già verificato l'autenticità dell'utente,
e quindi l'ID utente può semplicemente essere ottenuto dicendo req.user.
_ID, e l'ID di quell'utente,
assegnerò questo al campo dell'autore fuori dal commento.
Ora, quando il commento arriva,
il commento nel corpo del messaggio di richiesta
conterrà solo il campo di valutazione e il campo commento.
Ora non vogliamo inviare esplicitamente il campo autore più dal lato client,
invece che dovrebbe essere inserito automaticamente
sul lato server in base all'autenticità
dell'utente Questo è il punto che avevo
ribadito in questa modifica che ho fatto qui.
Pertanto, le informazioni degli utenti vengono ottenute automaticamente dal req.user che viene
caricato nel corpo del messaggio di richiesta dall'utente di verifica dell'autenticazione,
che utilizzerà l'autenticazione Passport con la strategia JWT lì.
Inoltre, ora quando riceviamo il piatto aggiornato qui,
dobbiamo popolare le informazioni dell'autore nel piatto.
Quindi, a questo punto,
quando riceviamo il piatto qui,
andremo a cercare i piatti qui.
Quindi, diremo piatti.FindById
e quindi fornire l'ID piatto come parametro qui,
quindi diremo trovare per ID,
ID piatto, e poi,
abbiamo bisogno di popolare l'autore commenti qui,
e poi diremo poi piatto.
Lì dentro, stiamo per inviare questa informazione piatto all'utente qui.
Quindi, lasciami tagliare e incollarlo qui.
Quindi, questa modifica è necessaria perché ora ho bisogno di popolare
le informazioni dell'autore
nel commento prima di poter inviare l'attuale all'utente.
Quindi, questa è l'ulteriore modifica che dobbiamo
fare quando usiamo la popolazione di Mangusta qui.
Allo stesso modo, ora entrando nel put,
quando modifichiamo un commento specifico con l'ID commento,
quindi questo è sotto il piatto ID commenti commento parte ID.
Quindi, quando facciamo il put qui,
quindi prima troviamo i piatti trovare da id req params dish ID,
poi nel piatto.
Quindi, la prima cosa che controlliamo è quello di garantire che se il piatto non è nullo,
e il piatto commenti ID non è nullo,
quindi abbiamo controllato per assicurarci che il commento sia effettivamente presente nel piatto,
e poi quando il piatto stesso viene restituito,
allora abbiamo bisogno di cercare di nuovo
il piatto perché abbiamo bisogno di popolare l'autore dei commenti nel piatto.
Quindi qui, diremo dishes.FindById (Dish ID),
il motivo per cui dobbiamo fare un'altra ricerca è perché
abbiamo bisogno di popolare i comments.author qui,
quindi questo è l'unico motivo per cui abbiamo bisogno di fare un'altra ricerca qui.
Poi quando riceviamo il piatto qui,
ovviamente perché abbiamo appena aggiornato il piatto in modo che le informazioni del piatto dovrebbero essere
trovate nel database, in
modo che dovrebbe funzionare bene e poi all'interno ci dirà
codice di stato del rischio 200 res set header content type application json,
e poi restituire il piatto qui,
e poi gestiremo l'errore qui,
e poi gli altri se i piatti
ora e anche gli altri errori che abbiamo impostato in precedenza,
saranno gestiti come al solito qui.
Quindi, queste sono le modifiche aggiuntive che dobbiamo assicurarci quando aggiorni il piatto,
quando stai inviando il commento aggiornato o il piatto aggiornato,
allora popoleremo il commento nel piatto qui.
Allo stesso modo, andando alla cancellazione qui,
e poi dopo l'eliminazione del commento, di
nuovo stiamo andando a recuperare il piatto e popolare le informazioni dell'autore.
Quindi, lasciami solo copiare questa parte,
e poi faremo esattamente la stessa cosa qui,
quindi diremo piatto salvare,
poi stiamo andando a controllare dish.FindByid (autore piatto),
e poi popoleremo l'autore commenti,
e poi diremo (poi) piatto,
e poi res.StatusCode, e così via,
e la gestione degli errori rimanente proprio come prima qui.
Quindi, con questa modifica al router piatto,
ora l'ultimo punto che dobbiamo considerare è il fatto che nel file user.js,
ora abbiamo aggiunto nei campi,
il nome e il cognome campo che per impostazione predefinita saranno stringhe vuote.
Quindi, quando l'utente si sta registrando,
dovremmo consentire all'utente di fornire il nome e
il cognome nel processo di registrazione.
Ora, dove si svolge?
Questo si svolge nel file.js dell'utente.
Quindi, andando agli utenti users.js,
quando l'utente pubblica la registrazione barra, in
precedenza stavamo solo postando il nome utente e la password.
Oltre a questi due,
nell'oggetto json che includiamo nel corpo del messaggio di richiesta in arrivo,
il messaggio di richiesta post che arriva dal lato client,
possiamo anche includere il nome e il cognome per l'utente.
Quindi, quando il nome e il cognome per l'utente sono inclusi,
quindi cosa ho intenzione di fare qui?
Quindi, ricorda che quando dici user.register a questo punto entrano le informazioni dell'utente,
e poi hai inviato il nome utente qui,
e hai anche assegnato la password qui che verrà
trasformata in hash e sale dalla mangusta locale del passaporto.
Ora, se non ci sono errori, significa che la registrazione dell'utente ha avuto successo,
e quindi a questo punto quello che faremo è diremo se req.body.
Nome. Quindi, il che significa che il corpo del messaggio di richiesta in arrivo,
se contiene il nome,
allora diremo user.firstname è uguale a req.body.firstname.
Allo stesso modo, anche per il cognome.
Quindi, a questo punto,
avremmo l'utente disponibile qui.
Vedi che l'utente sta arrivando come secondo parametro a questa funzione di callback qui.
Quindi, stiamo impostando il nome cambiando
la proprietà nome all'interno del documento utente qui dicendo, req.body.firstname.
Se esiste, allora imposteremo il nome dell'utente su quello.
Allo stesso modo, se il nome req.body.last è disponibile,
quindi aggiorneremo anche il cognome dell'utente come req.body.lastname.
E una volta che abbiamo fatto queste due modifiche al nome e al cognome,
allora abbiamo bisogno di salvare la modifica che abbiamo fatto all'utente.
Quindi, abbiamo appena aggiornato l'utente.
Quindi, diremo user.save quindi questo
restituirà l'errore o l'utente.
Quindi, se la modifica è stata salvata correttamente,
restituirà l'errore,
altrimenti restituirà il valore dell'utente e questo passaporto autenticato
lo faremo all'interno di questo utente qui.
Quindi, diremo, user.save (err, utente).
E poi anche dobbiamo controllare incrociando per assicurarci che
se c'è un errore nel salvare le modifiche all'utente,
allora diremo res status code 500,
quindi lasciami copiare questo da lì.
Quindi, diremo codice di stato res 500,
res set intestazione tipo di contenuto applicazione json e res.jason qui.
Poi, e torneremo a questo punto.
Se non ci sono errori,
ovviamente si autentica l'utente chiamando
l'autenticazione passaporto con il locale per assicurarsi che
la registrazione dell'utente abbia avuto successo e questo dovrebbe essere
fatto correttamente e quando in tal caso si restituirà questo messaggio al lato client.
Dobbiamo chiudere questo user.save qui.
Quindi, assicurarsi di chiudere correttamente questo endpoint.
Quindi, user.save è chiuso qui, e basta.
Queste sono le modifiche che dobbiamo apportare all'utente.
Quindi, dopo che l'utente è registrato con il nome utente specificato e la password data,
quindi dopo che l'utente è stato registrato con successo,
allora imposteremo il nome e
il cognome campo del documento utente utilizzando questi due qui.
Vogliamo assicurarci che l'utente sia
registrato correttamente prima di inviare il nome e il cognome per questo.
Quindi, ecco perché stiamo eseguendo questa operazione dopo che l'utente
è stato registrato con successo. Questo è tutto.
Salviamo le modifiche e andiamo a controllare il server.
Dopo aver salvato le modifiche,
andiamo ora al terminale e
poi prima di avviare il server,
lasciami prima controllare il mio MongoDB ed eliminare l'utente che abbiamo registrato in precedenza.
Quindi, diremo usa confusione e poi diremo db.usersfind.
Quindi, sappiamo che questo particolare utente è stato registrato in precedenza,
ma quando registriamo quell'utente,
non abbiamo registrato il nome e il cognome per l'utente.
Quindi, ho intenzione di eliminare questo utente e quindi ri-registrare l'utente.
Quindi, per farlo usando l'ondulazione Mongo, dirò che gli utenti db cadono,
e poi diremo
che gli utenti db trovano, e questo dovrebbe restituire un vuoto.
Nessun utente registrato lì e poi usciremo dall'ondulazione Mongo.
E così, una volta rimosso quell'utente registrato,
allora, lasciami avviare il mio server.
E una volta che il server è attivo e funzionante,
andiamo a Postman e poi registrare
un nuovo utente insieme al nome e cognome dell'utente.
Poi, si accederanno come tale utente e poi vedremo come
la popolazione Mangusta ci aiuta a popolare
automaticamente le informazioni sull'utente nel documento lì.
Ora andando a Postman,
lasciami fare un segno di un nuovo utente.
Quindi, sto facendo un post localhost: 3000 utenti si iscrivono.
Nel corpo del messaggio,
avevamo già il nome utente e la password.
Permettetemi di aggiungere due campi aggiuntivi:
nome, cognome.
Quindi, registrare l'utente.
Quindi, una volta registrato l'utente,
puoi vedere che la registrazione ha avuto successo.
Ora, lasciami accedere come questo utente.
Quindi, per accedere come utente,
lasciami fare un post e controllo incrociato per assicurarmene.
Quindi, sto facendo un post per accedere agli utenti.
Lasciami controllare e vedo che il nome utente e la password sono digitati correttamente lì.
Quindi, quando
accedo, dovrei essere connesso con successo e dovrei essere in grado di ottenere questo token lì.
Perché questo token è essenziale per noi per essere in grado di aggiungere un piatto al nostro sito server.
Quindi, dopo aver ottenuto il token,
copia questa stringa di token e salvala perché ne avrai bisogno
nell'intestazione di autorizzazione per le
operazioni post put ed delete che eseguirai in seguito.
Quindi fammi copiare quel gettone.
Ora, normalmente il modo in cui tengo questi token è,
che aprirò un documento di testo e poi lo copierò e incollerò nel documento di testo.
In modo che per le successive richieste di postino,
posso semplicemente copiare questa stringa e quindi incollarla
nell'intestazione di autorizzazione, se necessario.
Quindi, lasciami copiare quel token e qui ho un documento di testo aperto qui.
Quindi, ho intenzione di incollare quella stringa in questo documento di testo.
Quindi, qui abbiamo il token che abbiamo ottenuto.
Ora andiamo a postare un piatto al nostro server.
Tornando al postino,
fammi postare un piatto al server.
Quindi, questo è dove sceglierò il post qui.
Qui dentro, ho le informazioni del piatto che avevo usato in precedenza, ma per i commenti,
ora, ricordare che in precedenza avevamo il campo autore che stava memorizzando una stringa.
Quindi, tutti questi commenti non sono validi.
Quindi, ho intenzione di eliminare tutti questi commenti dalla presentazione perché,
ora, ci aspettiamo che l'utente pubblichi commenti da solo.
Quando l'utente pubblica commenti,
aggiungeremo automaticamente l'ID dell'utente nel campo autore dei commenti.
Quindi, lasciami postare questo piatto qui.
Andando all'intestazione,
nell'intestazione di autorizzazione, ho intenzione di dire,
portatore e poi, incollare il token e quindi inviare.
Dovrei fare un post su quello.
Quindi, dirò post e così quando posto ora,
si vede che questo piatto è stato pubblicato sul lato server,
e con l'array di commenti è vuoto in questo momento.
Quindi, dopo aver postato questo piatto,
fammi copiare l'ID di questo piatto.
Quindi, lasciami copiare questo ID per il piatto perché ne avrò
bisogno per postare commenti per questo piatto.
Poi, andando dal mio editor di testo,
ho intenzione di salvare l'ID del piatto qui.
Ora, naturalmente, una volta creato il lato client,
il cliente avrà automaticamente tutte queste informazioni.
Quindi, il tuo client sarà automaticamente in grado di inviare il token e così via.
Quindi, non è necessario fare questa cosa taglia-incolla, ma con il postino,
questo è l'unico modo in cui possiamo aggiungere qualsiasi informazione alle nostre richieste di postino,
che vanno dal postino al server.
Ora, al fine di convincerci che questo piatto esiste in realtà,
lasciami fare un get sul locale hostcolon:3000/piatti.
Quando faccio un get, si può effettivamente vedere che
questo particolare piatto esiste sul lato server.
Quindi, proviamo ora a postare un commento.
Quindi, per pubblicare un commento,
facciamo un post e diremo,
localhost: 3000/piatti, barra e l'ID del piatto che
ho appena copiato, e barra commenti.
Quando pubblichi sui commenti,
devi assicurarti che nel corpo aggiungeremo il commento qui.
Quindi, un commento tipico contiene
una valutazione di dire
cinque e poi commento.
Quindi, lasciami digitare qualche commento casuale,
solo per dimostrarti.
Quindi, questo dovrebbe essere nel corpo del post per i commenti e nell'intestazione,
dovremmo aggiungere l'intestazione di autorizzazione.
Quindi, per l'intestazione di autorizzazione, diremo, portatore.
Devo incollare il token qui,
incollando il valore del token che ho salvato in precedenza.
Vediamo ora pubblicare questo commento.
Quindi, quando il commento viene pubblicato,
diamo un'occhiata al valore restituito qui.
Quindi, mentre navighi verso il basso,
puoi vedere che il piatto a cui è stato aggiunto il commento, è stato restituito.
Si noti che le informazioni piatto è lì, ma nota in particolare,
ciò che è contenuto nel commento che è stato pubblicato qui.
Quindi, come puoi vedere, sai già che i
campi aggiornati e creati vengono aggiunti automaticamente da mangusta.
La valutazione e il commento che abbiamo inviato sono
proprio lì, ma nota come il campo autore
ora contiene l'ID corrispondente all'utente.
Ora, come abbiamo visto nel codice come vengono aggiunte le informazioni sul campo autore, ora,
se si fa un get sui piatti,
si noterà che questo campo autore verrà
automaticamente compilato dalle informazioni degli utenti qui.
Quindi, facciamo ora un get sul localhost: 3000/piatti.
Così, quando ora facciamo un get su questo punto,
ora noterete che nei piatti qui,
proprio lì, le informazioni sul piatto è già
presente, ma notare come il commento è ora costruito.
Il commento ora contiene,
i campi di commento di valutazione come abbiamo visto in precedenza,
l'aggiornato e creato a,
ma nota cosa è successo al campo autore qui.
Quindi, quando si esegue una richiesta get perché abbiamo fatto un popolamento
sul lato server quando viene richiamata l'operazione get,
il popolamento ha automaticamente popolato
le informazioni dell'autore in posizione nel campo autore qui.
Quindi, lì dentro, puoi vedere che dall'autore,
ora puoi cercare
automaticamente il cognome e le informazioni sul nome dal campo dell'autore.
Quindi, se hai bisogno di costruire un commento,
ora hai la valutazione,
il commento e anche il nome e il cognome
dell'autore inclusi automaticamente in questo documento.
Inoltre, il nome utente è incluso anche in questo documento.
Quindi, questo è il modo in cui è possibile aggiungere informazioni da un altro documento e popolare
un secondo documento con tali informazioni prima di rispondere dal sito server.
Quindi, questo è l'uso della popolazione mangusta e come
possiamo popolare automaticamente le informazioni in un documento mangusta.
Con questo, completiamo questo esercizio.
In questo esercizio, abbiamo visto l'uso della popolazione di mangusta e abbiamo anche visto
come possiamo popolare le informazioni da un documento a un altro documento. Per
cui, quando modifichiamo il server per fare la popolazione per le richieste,
mangusta si prenderà automaticamente cura di popolare queste informazioni per noi.
Tutto ciò che dobbiamo fare,
è quello di memorizzare il riferimento all'altro documento sotto forma di ID oggetto,
nel documento in cui si desidera popolare queste informazioni.
Con questo, completiamo questo esercizio.
Questo è un buon momento per fare un git-commit con il messaggio, popolazione mangusta.