1 00:00:03,920 --> 00:00:08,675 In questa lezione e l'esercizio che segue, 2 00:00:08,675 --> 00:00:12,000 parleremo specificamente di Callback Hell. 3 00:00:12,000 --> 00:00:15,330 Il problema che si verifica quando si scrivono 4 00:00:15,330 --> 00:00:19,980 callback nel nodo e in particolare callback e nodo nidificati. 5 00:00:19,980 --> 00:00:26,795 Considereremo anche le promesse come un modo per affrontare il problema dell'inferno di richiamata. 6 00:00:26,795 --> 00:00:34,340 Per darvi un'idea di ciò che si tradurrà il tipico problema di Callback Hell, 7 00:00:34,340 --> 00:00:40,115 rivisitiamo il file index.js dall'esercizio precedente. 8 00:00:40,115 --> 00:00:44,020 Mentre ne stavo parlando nell'esercizio precedente 9 00:00:44,020 --> 00:00:47,959 si nota che per ciascuna delle operazioni che eseguiamo, l' 10 00:00:47,959 --> 00:00:53,990 operazione successiva è inclusa all'interno della funzione di callback qui 11 00:00:53,990 --> 00:01:00,320 e così via fino a formare una struttura simile a piramide andare di nuovo. 12 00:01:00,320 --> 00:01:06,160 Quindi vedi questa struttura piramidale che sorge all'interno del tuo codice. 13 00:01:06,160 --> 00:01:11,540 Ora immagina di dover eseguire più operazioni nidificate come questa, 14 00:01:11,540 --> 00:01:13,850 il tuo codice diventerà molto presto, 15 00:01:13,850 --> 00:01:18,085 molto complesso e non così facile da decifrare. 16 00:01:18,085 --> 00:01:22,240 Ora questo è ciò che nel mondo node.js, 17 00:01:22,240 --> 00:01:25,830 si riferiscono a come Callback Hell. 18 00:01:25,960 --> 00:01:30,845 Ci sono stati diversi modi per mitigare il problema che si pone. 19 00:01:30,845 --> 00:01:35,690 Ora puoi evitarlo completamente a causa del fatto 20 00:01:35,690 --> 00:01:38,300 che hai determinate operazioni che devono essere 21 00:01:38,300 --> 00:01:41,480 completate prima che l'operazione successiva possa essere avviata, 22 00:01:41,480 --> 00:01:47,765 ma possiamo riorganizzare il codice in modo da mitigare questo problema. 23 00:01:47,765 --> 00:01:52,080 Le promesse sono uno di questi modi per affrontare questo. 24 00:01:52,080 --> 00:01:56,015 Quindi, per riassumere ciò che abbiamo appena discusso, il 25 00:01:56,015 --> 00:01:59,435 codice di callback fortemente annidato, 26 00:01:59,435 --> 00:02:02,990 causa il problema Callback Hell e 27 00:02:02,990 --> 00:02:07,010 deriva dalla nostra tendenza a scrivere programmi dall'alto verso il basso. 28 00:02:07,010 --> 00:02:11,990 Siamo ancora bloccati con il nostro modo sequenziale di scrivere codice e 29 00:02:11,990 --> 00:02:17,420 quindi vediamo più conveniente scrivere codice dall'alto verso il basso, 30 00:02:17,420 --> 00:02:21,145 e guardarlo come se stesse eseguendo in quell'ordine. 31 00:02:21,145 --> 00:02:24,140 Ora possiamo aggirare il problema Callback Hell 32 00:02:24,140 --> 00:02:27,460 non utilizzando funzioni anonime per i callback ma invece, 33 00:02:27,460 --> 00:02:30,870 dichiarando quelle funzioni con nomi specifici, 34 00:02:30,870 --> 00:02:35,630 e quindi evitare il modo in cui scriviamo il codice come hai visto qui. 35 00:02:35,630 --> 00:02:41,190 Questo è uno degli approcci che le persone adottano per affrontare il problema Callback Hell. 36 00:02:41,190 --> 00:02:44,990 Ci sono molti altri approcci che sono stati suggeriti, 37 00:02:44,990 --> 00:02:51,085 i collegamenti a un paio di articoli a questo proposito sono forniti nelle risorse aggiuntive. 38 00:02:51,085 --> 00:02:53,720 Ma in questa particolare lezione, 39 00:02:53,720 --> 00:02:56,810 mi concentrerò su un approccio particolare che 40 00:02:56,810 --> 00:03:00,275 viene utilizzato per affrontare il problema Callback Hell, 41 00:03:00,275 --> 00:03:02,370 cioè l'uso delle promesse. 42 00:03:02,370 --> 00:03:07,345 Quindi possiamo usare le promesse per domare il problema dell'inferno di callback in una certa misura. 43 00:03:07,345 --> 00:03:12,200 Vedremo come le promesse ci aiutano a questo proposito e 44 00:03:12,200 --> 00:03:17,180 nell'esercizio vedremo come perché il driver NODE-MONGO DB 45 00:03:17,180 --> 00:03:21,665 supporta già un'interfaccia proxy possiamo sfruttarlo per riscrivere il nostro codice 46 00:03:21,665 --> 00:03:27,495 per sfruttare il supporto promettente nel driver MONGO DB. 47 00:03:27,495 --> 00:03:31,455 Riassumendo brevemente cos'è una promessa. 48 00:03:31,455 --> 00:03:35,625 Una promessa è un meccanismo che supporta il calcolo asincrono. 49 00:03:35,625 --> 00:03:39,250 Quindi, se hai quantità di lavoro che deve essere fatto, 50 00:03:39,250 --> 00:03:43,550 la promessa funge da proxy per un valore che 51 00:03:43,550 --> 00:03:48,100 non è noto al momento ma la promessa è data a te. 52 00:03:48,100 --> 00:03:50,270 Ma quando il valore diventa disponibile, 53 00:03:50,270 --> 00:03:53,225 sarà disponibile in futuro. 54 00:03:53,225 --> 00:03:56,690 Quindi la promessa rappresenta un segnaposto per quel valore. 55 00:03:56,690 --> 00:03:58,795 Se il valore risulta correttamente, 56 00:03:58,795 --> 00:04:02,240 la tua promessa risulta correttamente e puoi avere 57 00:04:02,240 --> 00:04:08,735 un pezzo di codice eseguito per gestire il fatto che la promessa è stata risolta correttamente, in 58 00:04:08,735 --> 00:04:12,950 caso contrario gestisci l'errore in quella situazione. 59 00:04:12,950 --> 00:04:20,060 Quindi, una promessa si risolverà in risoluzione o il rifiuto della promessa. 60 00:04:20,060 --> 00:04:23,515 Una promessa in sospeso potrebbe risolvere 61 00:04:23,515 --> 00:04:27,105 quando il valore è ottenuto correttamente, quindi in quel caso, 62 00:04:27,105 --> 00:04:31,755 si risolverà o ciò che chiamiamo come adempimento della promessa. 63 00:04:31,755 --> 00:04:33,540 Quindi, quando la promessa viene risolta, 64 00:04:33,540 --> 00:04:35,960 avrai un pezzo di codice che 65 00:04:35,960 --> 00:04:38,760 gestisce il fatto che la promessa è stata risolta. 66 00:04:38,760 --> 00:04:40,455 Se la promessa viene rifiutata, 67 00:04:40,455 --> 00:04:43,985 dovresti anche gestire quella situazione 68 00:04:43,985 --> 00:04:48,470 il rifiuto della promessa corrispondentemente all'interno del tuo codice. 69 00:04:48,470 --> 00:04:52,400 Quindi questa è la ragione ogni volta che crei una promessa, 70 00:04:52,400 --> 00:04:56,680 fornisci solo le opzioni di risoluzione e rifiuto da essa. 71 00:04:56,680 --> 00:05:02,905 L' opzione di risoluzione è in genere gestita dal medico quindi opzione per la vostra promessa. 72 00:05:02,905 --> 00:05:05,960 Allora perché usiamo le promesse? 73 00:05:05,960 --> 00:05:08,060 Le promesse vengono utilizzate perché affronta 74 00:05:08,060 --> 00:05:13,130 il problema dell'inferno di callback in larga misura e le promesse possono essere modificate. 75 00:05:13,130 --> 00:05:15,860 Ad esempio, se hai una promessa che a 76 00:05:15,860 --> 00:05:20,690 sua volta attiva una chiamata a un'altra che restituirà una promessa. 77 00:05:20,690 --> 00:05:26,525 La gestione della promessa può essere modificata nell'handle della promessa precedente. 78 00:05:26,525 --> 00:05:28,315 Quindi puoi avere un sacco di 79 00:05:28,315 --> 00:05:33,635 chiamate, quindi che gestiranno il ritorno del valore. 80 00:05:33,635 --> 00:05:39,930 Ora vedremo l'uso di questo nell'esercizio che segue questa lezione. 81 00:05:39,930 --> 00:05:42,275 Per consumare una promessa, 82 00:05:42,275 --> 00:05:47,675 si registrerà una funzione di callback appropriata per 83 00:05:47,675 --> 00:05:50,810 quando al consumatore di una promessa viene notificata 84 00:05:50,810 --> 00:05:53,750 l'adempimento o il rifiuto della promessa. 85 00:05:53,750 --> 00:05:59,860 Quindi i callback sono registrati attraverso il.then () alla promessa. 86 00:05:59,860 --> 00:06:07,040 Userai il.catch () per rilevare gli errori all'interno della promessa di ritorno. 87 00:06:07,040 --> 00:06:09,845 Ora i metodi.then () possono essere incatenati 88 00:06:09,845 --> 00:06:15,205 insieme come si vedrà nell'esercizio che segue. 89 00:06:15,205 --> 00:06:19,730 Ad esempio, normalmente gestiresti una promessa 90 00:06:19,730 --> 00:06:26,250 concatenando il.then () e il.catch () al valore di promessa.