‫-: In questo video creiamo un
‫tipo speciale di middleware chiamato middleware param.
‫Quindi il middleware param è un middleware che viene eseguito
‫solo per determinati parametri, quindi in
‫pratica, quando abbiamo un determinato parametro nel nostro URL.
‫Ora nel nostro esempio qui, l'unico
‫parametro che potremmo avere nel nostro URL di route è l'id, giusto?
‫E così possiamo scrivere un middleware
‫che viene eseguito solo quando questo ID è
‫presente nell'URL, ok, quindi lascia che ti mostri come farlo.
‫In realtà è abbastanza semplice, quindi è
‫sul nostro router e poi sul metodo param, ok.
‫E quindi qui specifichiamo prima il parametro
‫che vogliamo effettivamente cercare, quindi fondamentalmente il
‫parametro per il quale
‫verrà eseguito questo middleware, e si chiama id, e
‫poi ovviamente la nostra effettiva funzione middleware.
‫E come al solito, abbiamo accesso alla richiesta
‫e all'oggetto risposta,
‫quindi rileva una funzione middleware
‫anche per la funzione successiva, giusto?
‫Ora in una funzione
‫middleware param, otteniamo effettivamente l'accesso a un quarto argomento
‫e quello è il valore del parametro in questione.
‫Quindi di solito lo chiamiamo one val, che sta per valore.
‫E quindi ora possiamo andare avanti
‫e semplicemente collegarlo
‫alla console, solo per dare un'occhiata se funziona davvero, quindi diciamo che
‫Tour id è e poi id, giusto?
‫Il prossimo, dobbiamo anche chiamare il prossimo, giusto?
‫Perché altrimenti il ciclo di risposta alla
‫richiesta si bloccherà in questa
‫funzione middleware e non sarà in grado
‫di passare al prossimo middleware nello stack, giusto?
‫Quali saranno queste rotte quaggiù.
‫Va bene, allora salviamolo e diamo un'occhiata adesso.
‫E lo vogliamo non per
‫ottenere tutti gli utenti ma per ottenere un tour, giusto?
‫Bene, lascia che
‫ti mostri prima cosa succede se non abbiamo alcun ID, ok, quindi
‫ora non vediamo alcun registro nella nostra console.
‫Ma se ora ho inviato la stessa
‫richiesta su questa rotta in cui abbiamo l'id, vediamo cosa succede allora.
‫Oh, mi dice che id non è definito,
‫e in effetti non è id, quindi è stato uno stupido errore.
‫Quindi è valore per valore, giusto?
‫Quindi ricorda come ho detto che questo parametro value
‫è quello che conterrà
‫effettivamente il valore del parametro id, e quindi
‫ovviamente è quello che dobbiamo quindi usare
‫qui per ottenere l'accesso a quell'id.
‫Quindi proviamo di nuovo, e ora
‫abbiamo davvero l'id del Tour è due, giusto?
‫Quindi quel registro è venuto proprio da questa funzione qui.
‫Ora, quello che voglio
‫anche mostrarvi è che questa funzione middleware
‫non verrà eseguita per nessuna delle route dell'utente.
‫Quindi diciamo che chiamiamo un utente con un ID specifico, quindi
‫andiamo avanti e copiamo questo
‫qui, creiamo una nuova richiesta con un ID e mi
‫permetta di salvarlo effettivamente.
‫Quindi ottieni utente e salva su utente, e quando lo invio qui ovviamente
‫otteniamo la nostra risposta standard
‫di questo percorso non definito, ma vedi
‫anche che non abbiamo alcun registro come prima.
‫E questo è ovviamente dovuto al fatto che questa funzione
‫middleware è specificata solo nel nostro router tour.
‫Quindi in questo tipo di mini applicazione locale,
‫di nuovo, questa è l'analogia che mi piace fare.
‫Quindi fondamentalmente ogni router
‫è una specie di mini sotto-applicazione, una per ogni risorsa.
‫E quindi poiché questo middleware è specificato solo su questo
‫router, beh, ovviamente, è
‫solo una parte dello stack
‫del middleware se siamo effettivamente all'interno di questa sottoapplicazione.
‫Ha senso?
‫Quindi supponiamo di avere una richiesta in arrivo su tour/id.
‫Quindi quella richiesta passerà attraverso tutti questi middleware, quindi
‫prima questo middleware, poi questo, poi
‫questo middleware, poi questo, quindi tutti questi fanno
‫parte dello stack del middleware e
‫infine colpirà questo middleware e poiché
‫questo è effettivamente il
‫percorso, verrà quindi inserito nel middleware tourRouter.
‫Ok, quindi da lì passa direttamente a questo middleware
‫e quindi verrà eseguito questo codice.
‫E ancora, è solo perché ha un ID nel percorso.
‫In caso contrario, beh, allora questo verrebbe
‫semplicemente ignorato e passerebbe direttamente
‫al prossimo middleware nello stack, quindi questi quaggiù, giusto?
‫Fantastico, ecco come funziona il middleware param; ma per
‫ora non è poi così utile.
‫Ma possiamo effettivamente usarlo
‫per un caso d'uso molto pratico qui.
‫Quindi andiamo alle nostre funzioni di gestione qui
‫e vedrai che in tutte le funzioni
‫di gestione che usano effettivamente l'id, controlliamo se l'id è valido.
‫Quindi lo facciamo qui in get tour, e lo
‫facciamo anche in update tour, quindi qui, e in delete tour.
‫Quindi tutte queste tre funzioni hanno questo codice molto
‫simile in cui controllano se l'id
‫è valido e, in caso contrario, inviano questa risposta ID non valido.
‫Quindi abbiamo tutto questo codice nello stesso
‫posto e come già sai, non è una
‫buona pratica ripetere il codice e quindi quello che
‫possiamo fare qui è usare il concetto di
‫middleware param; ed esegui questo controllo qui in un
‫middleware esterno che verrà eseguito
‫prima che la richiesta raggiunga queste funzioni del gestore.
‫Quindi andiamo avanti e copiamo o tagliamo
‫effettivamente il codice da qui e creiamo una
‫nuova funzione middleware chiamata checkID, e ovviamente ho anche bisogno di esportarlo.
‫Quindi checkID e abbiamo accesso, richiesta, risposta, avanti e
‫ancora, tieni presente che è un middleware param
‫e quindi il quarto argomento sarà
‫il valore del parametro.
‫Ok, incollalo qui e poi non
‫dimenticare di chiamare Next alla fine del middleware, ok?
‫E ciò che è anche molto
‫importante è che abbiamo questa istruzione return qui,
‫perché se non avessimo questo ritorno qui,
‫beh, allora express invierebbe questa risposta ma continuerebbe comunque
‫a eseguire il
‫codice in questa funzione.
‫E così, dopo aver
‫inviato la risposta, eseguirà ancora questa funzione
‫successiva e passerà al middleware successivo
‫e quindi invierà un'altra risposta al client.
‫Ma questo in realtà non è
‫consentito, quindi ricorda che in realtà ci siamo imbattuti in questo errore
‫prima, in cui ci diceva che non ci
‫era permesso inviare intestazioni dopo che la risposta era già stata inviata.
‫E quindi questo è
‫il tipo di errore in cui ci
‫imbatteremmo se non avessimo questa dichiarazione di ritorno, ok.
‫Quindi, di nuovo, assicurati che dopo aver inviato questa
‫risposta, la funzione ritorni in modo
‫che finisca e non la chiamerà mai.
‫Quindi non dimenticarlo mai, ma ovviamente
‫lo faremo più volte
‫durante il resto del corso
‫e così ti abituerai a questo tipo di schema.
‫Quindi andiamo avanti e rimuoviamo questo codice ripetuto da
‫tutte queste altre funzioni,
‫quindi eccolo di nuovo, e sì.
‫Voglio anche questo codice qui solo per
‫assicurarmi che la funzione sia
‫effettivamente in esecuzione, e va bene, quindi ora possiamo sbarazzarci di questo
‫qui e sostituirlo con la nostra funzione controller appena creata.
‫Quindi tourController,
‫checkID, quindi controlliamolo ora,
‫e di nuovo bene, solo per assicurarci
‫che non venga
‫eseguito dove non abbiamo un id, quindi non abbiamo alcun registro
‫qui, quindi tutto funziona ancora su quel lato.
‫E ora fai un tour con un
‫ID normale, quindi un ID valido, e quindi vediamo.
‫Bene, otteniamo che l'ID Tour è log, quindi
‫ciò significa che se ha
‫effettivamente eseguito il nostro middleware checkID, giusto?
‫E se ora proviamo un ID
‫non valido, allora otteniamo il nostro messaggio ID
‫non valido, il codice di errore 404 e, naturalmente, il nostro ID tour.
‫Facciamo lo stesso con la patch,
‫abbiamo già un ID non
‫valido qui e quindi funziona anche su questa.
‫Quindi, perfetto, no?
‫Quindi non abbiamo più il codice checkID nel gestore
‫degli aggiornamenti che abbiamo appena invocato in pratica, ma il
‫nostro ID è ancora controllato
‫perché abbiamo quel middleware, quindi questo qui.
‫Abbiamo quel middleware nello
‫stack prima che colpisca effettivamente l'aggiornamento tourController.
‫Quindi questo middleware fa ora parte della nostra
‫pipeline come puoi immaginarlo, ora potresti
‫sostenere che potremmo semplicemente creare una
‫semplice funzione che potrebbe anche
‫controllare l'ID e chiamo quella funzione
‫all'interno di ciascuna di queste funzioni tour, quindi chiamo
‫it all'interno di ciascuno di questi tour controller rilevanti; ma
‫ciò andrebbe
‫davvero contro la filosofia di express, dove dovremmo
‫sempre lavorare con lo stack middleware, quindi
‫con questa pipeline il più possibile, ok, e quindi queste funzioni
‫qui, non devono preoccuparsi affatto della convalida.
‫Ognuna di queste funzioni ha un solo scopo che è
‫quello di fare quello che dicono,
‫quindi questa ottiene solo il
‫tour, questa crea solo un tour, questa si aggiorna solo e
‫questa si limita a cancellare, non controlla, non
‫non devi preoccuparti di niente di tutto ciò.
‫E se ora aggiungiamo
‫un altro controller qui anche a seconda dell'id, beh,
‫allora ciò verificherebbe automaticamente anche se l'id
‫non è valido senza che dobbiamo eseguire ulteriori passaggi.
‫Quindi questo controllerà automaticamente l'id e quindi
‫è davvero utile e anche come dovrebbero funzionare
‫le app express, fantastico.
‫Quindi abbiamo un altro strumento nella nostra cassetta degli attrezzi express che
‫ora possiamo usare per scrivere le nostre applicazioni express.