1 00:00:01,220 --> 00:00:03,730 ‫-: In questo video creiamo un 2 00:00:03,730 --> 00:00:06,333 ‫tipo speciale di middleware chiamato middleware param. 3 00:00:07,920 --> 00:00:11,460 ‫Quindi il middleware param è un middleware che viene eseguito 4 00:00:11,460 --> 00:00:13,940 ‫solo per determinati parametri, quindi in 5 00:00:13,940 --> 00:00:17,450 ‫pratica, quando abbiamo un determinato parametro nel nostro URL. 6 00:00:17,450 --> 00:00:20,000 ‫Ora nel nostro esempio qui, l'unico 7 00:00:20,000 --> 00:00:25,000 ‫parametro che potremmo avere nel nostro URL di route è l'id, giusto? 8 00:00:25,320 --> 00:00:28,120 ‫E così possiamo scrivere un middleware 9 00:00:28,120 --> 00:00:31,100 ‫che viene eseguito solo quando questo ID è 10 00:00:31,100 --> 00:00:34,570 ‫presente nell'URL, ok, quindi lascia che ti mostri come farlo. 11 00:00:34,570 --> 00:00:38,000 ‫In realtà è abbastanza semplice, quindi è 12 00:00:39,690 --> 00:00:43,260 ‫sul nostro router e poi sul metodo param, ok. 13 00:00:43,260 --> 00:00:46,210 ‫E quindi qui specifichiamo prima il parametro 14 00:00:46,210 --> 00:00:48,890 ‫che vogliamo effettivamente cercare, quindi fondamentalmente il 15 00:00:48,890 --> 00:00:50,900 ‫parametro per il quale 16 00:00:50,900 --> 00:00:54,400 ‫verrà eseguito questo middleware, e si chiama id, e 17 00:00:54,400 --> 00:00:57,333 ‫poi ovviamente la nostra effettiva funzione middleware. 18 00:00:59,060 --> 00:01:02,800 ‫E come al solito, abbiamo accesso alla richiesta 19 00:01:02,800 --> 00:01:05,070 ‫e all'oggetto risposta, 20 00:01:05,070 --> 00:01:07,350 ‫quindi rileva una funzione middleware 21 00:01:07,350 --> 00:01:10,300 ‫anche per la funzione successiva, giusto? 22 00:01:10,300 --> 00:01:12,090 ‫Ora in una funzione 23 00:01:12,090 --> 00:01:15,370 ‫middleware param, otteniamo effettivamente l'accesso a un quarto argomento 24 00:01:15,370 --> 00:01:18,783 ‫e quello è il valore del parametro in questione. 25 00:01:20,280 --> 00:01:23,553 ‫Quindi di solito lo chiamiamo one val, che sta per valore. 26 00:01:26,240 --> 00:01:28,720 ‫E quindi ora possiamo andare avanti 27 00:01:28,720 --> 00:01:30,650 ‫e semplicemente collegarlo 28 00:01:30,650 --> 00:01:35,510 ‫alla console, solo per dare un'occhiata se funziona davvero, quindi diciamo che 29 00:01:37,700 --> 00:01:40,410 ‫Tour id è e poi id, giusto? 30 00:01:40,410 --> 00:01:43,840 ‫Il prossimo, dobbiamo anche chiamare il prossimo, giusto? 31 00:01:43,840 --> 00:01:46,470 ‫Perché altrimenti il ciclo di risposta alla 32 00:01:46,470 --> 00:01:48,970 ‫richiesta si bloccherà in questa 33 00:01:48,970 --> 00:01:51,630 ‫funzione middleware e non sarà in grado 34 00:01:51,630 --> 00:01:54,570 ‫di passare al prossimo middleware nello stack, giusto? 35 00:01:54,570 --> 00:01:56,903 ‫Quali saranno queste rotte quaggiù. 36 00:01:57,860 --> 00:02:01,563 ‫Va bene, allora salviamolo e diamo un'occhiata adesso. 37 00:02:03,000 --> 00:02:05,260 ‫E lo vogliamo non per 38 00:02:06,370 --> 00:02:10,100 ‫ottenere tutti gli utenti ma per ottenere un tour, giusto? 39 00:02:10,100 --> 00:02:11,940 ‫Bene, lascia che 40 00:02:11,940 --> 00:02:16,940 ‫ti mostri prima cosa succede se non abbiamo alcun ID, ok, quindi 41 00:02:17,020 --> 00:02:20,310 ‫ora non vediamo alcun registro nella nostra console. 42 00:02:20,310 --> 00:02:22,870 ‫Ma se ora ho inviato la stessa 43 00:02:22,870 --> 00:02:26,843 ‫richiesta su questa rotta in cui abbiamo l'id, vediamo cosa succede allora. 44 00:02:26,843 --> 00:02:29,610 ‫Oh, mi dice che id non è definito, 45 00:02:29,610 --> 00:02:33,500 ‫e in effetti non è id, quindi è stato uno stupido errore. 46 00:02:33,500 --> 00:02:36,420 ‫Quindi è valore per valore, giusto? 47 00:02:36,420 --> 00:02:39,710 ‫Quindi ricorda come ho detto che questo parametro value 48 00:02:39,710 --> 00:02:41,500 ‫è quello che conterrà 49 00:02:41,500 --> 00:02:44,400 ‫effettivamente il valore del parametro id, e quindi 50 00:02:44,400 --> 00:02:46,930 ‫ovviamente è quello che dobbiamo quindi usare 51 00:02:46,930 --> 00:02:49,303 ‫qui per ottenere l'accesso a quell'id. 52 00:02:50,280 --> 00:02:53,580 ‫Quindi proviamo di nuovo, e ora 53 00:02:53,580 --> 00:02:56,990 ‫abbiamo davvero l'id del Tour è due, giusto? 54 00:02:56,990 --> 00:03:00,120 ‫Quindi quel registro è venuto proprio da questa funzione qui. 55 00:03:00,120 --> 00:03:01,893 ‫Ora, quello che voglio 56 00:03:01,893 --> 00:03:04,160 ‫anche mostrarvi è che questa funzione middleware 57 00:03:04,160 --> 00:03:07,003 ‫non verrà eseguita per nessuna delle route dell'utente. 58 00:03:08,963 --> 00:03:13,380 ‫Quindi diciamo che chiamiamo un utente con un ID specifico, quindi 59 00:03:13,380 --> 00:03:15,593 ‫andiamo avanti e copiamo questo 60 00:03:16,770 --> 00:03:20,680 ‫qui, creiamo una nuova richiesta con un ID e mi 61 00:03:20,680 --> 00:03:22,493 ‫permetta di salvarlo effettivamente. 62 00:03:25,250 --> 00:03:30,240 ‫Quindi ottieni utente e salva su utente, e quando lo invio qui ovviamente 63 00:03:30,240 --> 00:03:32,340 ‫otteniamo la nostra risposta standard 64 00:03:32,340 --> 00:03:35,200 ‫di questo percorso non definito, ma vedi 65 00:03:35,200 --> 00:03:38,210 ‫anche che non abbiamo alcun registro come prima. 66 00:03:38,210 --> 00:03:41,800 ‫E questo è ovviamente dovuto al fatto che questa funzione 67 00:03:41,800 --> 00:03:44,940 ‫middleware è specificata solo nel nostro router tour. 68 00:03:44,940 --> 00:03:48,280 ‫Quindi in questo tipo di mini applicazione locale, 69 00:03:48,280 --> 00:03:51,750 ‫di nuovo, questa è l'analogia che mi piace fare. 70 00:03:51,750 --> 00:03:53,960 ‫Quindi fondamentalmente ogni router 71 00:03:53,960 --> 00:03:58,040 ‫è una specie di mini sotto-applicazione, una per ogni risorsa. 72 00:03:58,040 --> 00:04:02,210 ‫E quindi poiché questo middleware è specificato solo su questo 73 00:04:02,210 --> 00:04:04,300 ‫router, beh, ovviamente, è 74 00:04:04,300 --> 00:04:06,680 ‫solo una parte dello stack 75 00:04:06,680 --> 00:04:10,670 ‫del middleware se siamo effettivamente all'interno di questa sottoapplicazione. 76 00:04:10,670 --> 00:04:11,780 ‫Ha senso? 77 00:04:11,780 --> 00:04:16,460 ‫Quindi supponiamo di avere una richiesta in arrivo su tour/id. 78 00:04:16,460 --> 00:04:20,110 ‫Quindi quella richiesta passerà attraverso tutti questi middleware, quindi 79 00:04:20,110 --> 00:04:22,900 ‫prima questo middleware, poi questo, poi 80 00:04:22,900 --> 00:04:26,190 ‫questo middleware, poi questo, quindi tutti questi fanno 81 00:04:26,190 --> 00:04:28,700 ‫parte dello stack del middleware e 82 00:04:28,700 --> 00:04:31,360 ‫infine colpirà questo middleware e poiché 83 00:04:31,360 --> 00:04:33,660 ‫questo è effettivamente il 84 00:04:33,660 --> 00:04:36,650 ‫percorso, verrà quindi inserito nel middleware tourRouter. 85 00:04:36,650 --> 00:04:40,830 ‫Ok, quindi da lì passa direttamente a questo middleware 86 00:04:40,830 --> 00:04:43,823 ‫e quindi verrà eseguito questo codice. 87 00:04:45,650 --> 00:04:48,830 ‫E ancora, è solo perché ha un ID nel percorso. 88 00:04:48,830 --> 00:04:51,970 ‫In caso contrario, beh, allora questo verrebbe 89 00:04:51,970 --> 00:04:54,540 ‫semplicemente ignorato e passerebbe direttamente 90 00:04:54,540 --> 00:04:58,097 ‫al prossimo middleware nello stack, quindi questi quaggiù, giusto? 91 00:04:58,097 --> 00:05:01,770 ‫Fantastico, ecco come funziona il middleware param; ma per 92 00:05:01,770 --> 00:05:04,296 ‫ora non è poi così utile. 93 00:05:04,296 --> 00:05:06,170 ‫Ma possiamo effettivamente usarlo 94 00:05:06,170 --> 00:05:08,430 ‫per un caso d'uso molto pratico qui. 95 00:05:08,430 --> 00:05:11,670 ‫Quindi andiamo alle nostre funzioni di gestione qui 96 00:05:11,670 --> 00:05:14,800 ‫e vedrai che in tutte le funzioni 97 00:05:14,800 --> 00:05:19,023 ‫di gestione che usano effettivamente l'id, controlliamo se l'id è valido. 98 00:05:20,080 --> 00:05:24,560 ‫Quindi lo facciamo qui in get tour, e lo 99 00:05:24,560 --> 00:05:29,470 ‫facciamo anche in update tour, quindi qui, e in delete tour. 100 00:05:29,470 --> 00:05:32,250 ‫Quindi tutte queste tre funzioni hanno questo codice molto 101 00:05:32,250 --> 00:05:34,370 ‫simile in cui controllano se l'id 102 00:05:34,370 --> 00:05:38,010 ‫è valido e, in caso contrario, inviano questa risposta ID non valido. 103 00:05:38,010 --> 00:05:40,360 ‫Quindi abbiamo tutto questo codice nello stesso 104 00:05:40,360 --> 00:05:43,100 ‫posto e come già sai, non è una 105 00:05:43,100 --> 00:05:46,020 ‫buona pratica ripetere il codice e quindi quello che 106 00:05:46,020 --> 00:05:48,750 ‫possiamo fare qui è usare il concetto di 107 00:05:48,750 --> 00:05:51,680 ‫middleware param; ed esegui questo controllo qui in un 108 00:05:51,680 --> 00:05:53,660 ‫middleware esterno che verrà eseguito 109 00:05:53,660 --> 00:05:56,483 ‫prima che la richiesta raggiunga queste funzioni del gestore. 110 00:05:57,690 --> 00:06:01,010 ‫Quindi andiamo avanti e copiamo o tagliamo 111 00:06:01,010 --> 00:06:04,761 ‫effettivamente il codice da qui e creiamo una 112 00:06:04,761 --> 00:06:09,761 ‫nuova funzione middleware chiamata checkID, e ovviamente ho anche bisogno di esportarlo. 113 00:06:14,010 --> 00:06:18,344 ‫Quindi checkID e abbiamo accesso, richiesta, risposta, avanti e 114 00:06:18,344 --> 00:06:21,980 ‫ancora, tieni presente che è un middleware param 115 00:06:21,980 --> 00:06:25,150 ‫e quindi il quarto argomento sarà 116 00:06:25,150 --> 00:06:27,353 ‫il valore del parametro. 117 00:06:29,040 --> 00:06:32,090 ‫Ok, incollalo qui e poi non 118 00:06:32,090 --> 00:06:36,570 ‫dimenticare di chiamare Next alla fine del middleware, ok? 119 00:06:36,570 --> 00:06:38,650 ‫E ciò che è anche molto 120 00:06:38,650 --> 00:06:41,402 ‫importante è che abbiamo questa istruzione return qui, 121 00:06:41,402 --> 00:06:44,010 ‫perché se non avessimo questo ritorno qui, 122 00:06:44,010 --> 00:06:47,360 ‫beh, allora express invierebbe questa risposta ma continuerebbe comunque 123 00:06:47,360 --> 00:06:48,930 ‫a eseguire il 124 00:06:48,930 --> 00:06:50,550 ‫codice in questa funzione. 125 00:06:50,550 --> 00:06:52,510 ‫E così, dopo aver 126 00:06:52,510 --> 00:06:55,170 ‫inviato la risposta, eseguirà ancora questa funzione 127 00:06:55,170 --> 00:06:57,670 ‫successiva e passerà al middleware successivo 128 00:06:57,670 --> 00:07:00,560 ‫e quindi invierà un'altra risposta al client. 129 00:07:00,560 --> 00:07:02,500 ‫Ma questo in realtà non è 130 00:07:02,500 --> 00:07:05,930 ‫consentito, quindi ricorda che in realtà ci siamo imbattuti in questo errore 131 00:07:05,930 --> 00:07:08,150 ‫prima, in cui ci diceva che non ci 132 00:07:08,150 --> 00:07:11,520 ‫era permesso inviare intestazioni dopo che la risposta era già stata inviata. 133 00:07:11,520 --> 00:07:13,030 ‫E quindi questo è 134 00:07:13,030 --> 00:07:14,990 ‫il tipo di errore in cui ci 135 00:07:14,990 --> 00:07:17,380 ‫imbatteremmo se non avessimo questa dichiarazione di ritorno, ok. 136 00:07:17,380 --> 00:07:20,880 ‫Quindi, di nuovo, assicurati che dopo aver inviato questa 137 00:07:20,880 --> 00:07:23,460 ‫risposta, la funzione ritorni in modo 138 00:07:23,460 --> 00:07:26,350 ‫che finisca e non la chiamerà mai. 139 00:07:26,350 --> 00:07:28,350 ‫Quindi non dimenticarlo mai, ma ovviamente 140 00:07:28,350 --> 00:07:30,010 ‫lo faremo più volte 141 00:07:30,010 --> 00:07:31,720 ‫durante il resto del corso 142 00:07:31,720 --> 00:07:34,823 ‫e così ti abituerai a questo tipo di schema. 143 00:07:36,096 --> 00:07:39,570 ‫Quindi andiamo avanti e rimuoviamo questo codice ripetuto da 144 00:07:39,570 --> 00:07:41,230 ‫tutte queste altre funzioni, 145 00:07:44,756 --> 00:07:47,197 ‫quindi eccolo di nuovo, e sì. 146 00:07:49,740 --> 00:07:52,352 ‫Voglio anche questo codice qui solo per 147 00:07:52,352 --> 00:07:54,903 ‫assicurarmi che la funzione sia 148 00:07:57,910 --> 00:08:02,510 ‫effettivamente in esecuzione, e va bene, quindi ora possiamo sbarazzarci di questo 149 00:08:02,510 --> 00:08:06,640 ‫qui e sostituirlo con la nostra funzione controller appena creata. 150 00:08:06,640 --> 00:08:07,990 ‫Quindi tourController, 151 00:08:11,550 --> 00:08:13,143 ‫checkID, quindi controlliamolo ora, 152 00:08:15,180 --> 00:08:18,370 ‫e di nuovo bene, solo per assicurarci 153 00:08:18,370 --> 00:08:19,860 ‫che non venga 154 00:08:19,860 --> 00:08:24,350 ‫eseguito dove non abbiamo un id, quindi non abbiamo alcun registro 155 00:08:24,350 --> 00:08:27,810 ‫qui, quindi tutto funziona ancora su quel lato. 156 00:08:27,810 --> 00:08:30,670 ‫E ora fai un tour con un 157 00:08:30,670 --> 00:08:33,883 ‫ID normale, quindi un ID valido, e quindi vediamo. 158 00:08:34,750 --> 00:08:38,040 ‫Bene, otteniamo che l'ID Tour è log, quindi 159 00:08:38,040 --> 00:08:40,346 ‫ciò significa che se ha 160 00:08:40,346 --> 00:08:43,563 ‫effettivamente eseguito il nostro middleware checkID, giusto? 161 00:08:44,560 --> 00:08:46,986 ‫E se ora proviamo un ID 162 00:08:46,986 --> 00:08:50,090 ‫non valido, allora otteniamo il nostro messaggio ID 163 00:08:50,090 --> 00:08:54,803 ‫non valido, il codice di errore 404 e, naturalmente, il nostro ID tour. 164 00:08:56,200 --> 00:08:58,930 ‫Facciamo lo stesso con la patch, 165 00:08:58,930 --> 00:09:01,240 ‫abbiamo già un ID non 166 00:09:01,240 --> 00:09:04,740 ‫valido qui e quindi funziona anche su questa. 167 00:09:04,740 --> 00:09:08,420 ‫Quindi, perfetto, no? 168 00:09:08,420 --> 00:09:11,865 ‫Quindi non abbiamo più il codice checkID nel gestore 169 00:09:11,865 --> 00:09:15,910 ‫degli aggiornamenti che abbiamo appena invocato in pratica, ma il 170 00:09:15,910 --> 00:09:18,240 ‫nostro ID è ancora controllato 171 00:09:18,240 --> 00:09:21,470 ‫perché abbiamo quel middleware, quindi questo qui. 172 00:09:21,470 --> 00:09:23,630 ‫Abbiamo quel middleware nello 173 00:09:23,630 --> 00:09:26,750 ‫stack prima che colpisca effettivamente l'aggiornamento tourController. 174 00:09:26,750 --> 00:09:30,200 ‫Quindi questo middleware fa ora parte della nostra 175 00:09:30,200 --> 00:09:32,770 ‫pipeline come puoi immaginarlo, ora potresti 176 00:09:32,770 --> 00:09:35,340 ‫sostenere che potremmo semplicemente creare una 177 00:09:35,340 --> 00:09:37,530 ‫semplice funzione che potrebbe anche 178 00:09:37,530 --> 00:09:40,220 ‫controllare l'ID e chiamo quella funzione 179 00:09:40,220 --> 00:09:43,910 ‫all'interno di ciascuna di queste funzioni tour, quindi chiamo 180 00:09:43,910 --> 00:09:47,830 ‫it all'interno di ciascuno di questi tour controller rilevanti; ma 181 00:09:47,830 --> 00:09:49,410 ‫ciò andrebbe 182 00:09:49,410 --> 00:09:52,860 ‫davvero contro la filosofia di express, dove dovremmo 183 00:09:52,860 --> 00:09:55,730 ‫sempre lavorare con lo stack middleware, quindi 184 00:09:55,730 --> 00:10:00,010 ‫con questa pipeline il più possibile, ok, e quindi queste funzioni 185 00:10:00,010 --> 00:10:02,850 ‫qui, non devono preoccuparsi affatto della convalida. 186 00:10:02,850 --> 00:10:05,580 ‫Ognuna di queste funzioni ha un solo scopo che è 187 00:10:05,580 --> 00:10:07,540 ‫quello di fare quello che dicono, 188 00:10:07,540 --> 00:10:09,200 ‫quindi questa ottiene solo il 189 00:10:09,200 --> 00:10:12,170 ‫tour, questa crea solo un tour, questa si aggiorna solo e 190 00:10:12,170 --> 00:10:14,650 ‫questa si limita a cancellare, non controlla, non 191 00:10:14,650 --> 00:10:17,003 ‫non devi preoccuparti di niente di tutto ciò. 192 00:10:18,910 --> 00:10:21,060 ‫E se ora aggiungiamo 193 00:10:21,060 --> 00:10:24,630 ‫un altro controller qui anche a seconda dell'id, beh, 194 00:10:24,630 --> 00:10:27,380 ‫allora ciò verificherebbe automaticamente anche se l'id 195 00:10:27,380 --> 00:10:30,960 ‫non è valido senza che dobbiamo eseguire ulteriori passaggi. 196 00:10:30,960 --> 00:10:34,620 ‫Quindi questo controllerà automaticamente l'id e quindi 197 00:10:34,620 --> 00:10:38,670 ‫è davvero utile e anche come dovrebbero funzionare 198 00:10:38,670 --> 00:10:41,450 ‫le app express, fantastico. 199 00:10:41,450 --> 00:10:45,810 ‫Quindi abbiamo un altro strumento nella nostra cassetta degli attrezzi express che 200 00:10:45,810 --> 00:10:49,493 ‫ora possiamo usare per scrivere le nostre applicazioni express.