1 00:00:03,920 --> 00:00:08,675 Nesta palestra e no exercício que se segue, 2 00:00:08,675 --> 00:00:12,000 vamos falar especificamente sobre Callback Hell. 3 00:00:12,000 --> 00:00:15,330 O problema que surge quando escreve 4 00:00:15,330 --> 00:00:19,980 retornos de chamada no nó e especialmente aninhados callbacks e nó. 5 00:00:19,980 --> 00:00:26,795 Nós também olharemos para as promessas como uma maneira de lidar com o problema do Inferno de Callback. 6 00:00:26,795 --> 00:00:34,340 Para lhe dar uma idéia do que o problema típico do Callback Hell resultará, 7 00:00:34,340 --> 00:00:40,115 vamos revisitar o arquivo index.js do exercício anterior. 8 00:00:40,115 --> 00:00:44,020 Como eu estava falando sobre isso no exercício anterior 9 00:00:44,020 --> 00:00:47,959 você percebe que para cada uma das operações que realizamos, 10 00:00:47,959 --> 00:00:53,990 a operação subsequente é incluída dentro da função callback aqui 11 00:00:53,990 --> 00:01:00,320 e assim por diante até que você formar uma pirâmide como estrutura ir novamente. 12 00:01:00,320 --> 00:01:06,160 Então você vê essa pirâmide como estrutura surgindo dentro de seu código. 13 00:01:06,160 --> 00:01:11,540 Agora imagine que você precisa executar várias operações aninhadas como esta, 14 00:01:11,540 --> 00:01:13,850 seu código se tornará muito em breve, 15 00:01:13,850 --> 00:01:18,085 muito complexo e não tão fácil de decifrar. 16 00:01:18,085 --> 00:01:22,240 Agora isso é o que no mundo node.js, 17 00:01:22,240 --> 00:01:25,830 eles se referem como Callback Hell. 18 00:01:25,960 --> 00:01:30,845 Houve várias maneiras de mitigar o problema que surge. 19 00:01:30,845 --> 00:01:35,690 Agora você pode evitar isso completamente devido ao fato de 20 00:01:35,690 --> 00:01:38,300 que você tem certas operações que precisam ser 21 00:01:38,300 --> 00:01:41,480 concluídas antes que a próxima operação possa ser iniciada, 22 00:01:41,480 --> 00:01:47,765 mas podemos reorganizar o código de forma a mitigar esse problema. 23 00:01:47,765 --> 00:01:52,080 Promessas de ser uma dessas formas de lidar com isso. 24 00:01:52,080 --> 00:01:56,015 Então, para resumir o que acabamos de discutir, 25 00:01:56,015 --> 00:01:59,435 código de retorno de chamada fortemente aninhado, 26 00:01:59,435 --> 00:02:02,990 causa o problema Callback Hell e isso 27 00:02:02,990 --> 00:02:07,010 resulta da nossa tendência de escrever programas de cima para baixo. 28 00:02:07,010 --> 00:02:11,990 Ainda estamos desligados com a nossa maneira sequencial de escrever código e 29 00:02:11,990 --> 00:02:17,420 por isso vemos mais conveniente escrever código de cima para baixo, 30 00:02:17,420 --> 00:02:21,145 e olhá-lo como se ele estivesse sendo executado nessa ordem. 31 00:02:21,145 --> 00:02:24,140 Agora podemos contornar o problema do Callback Hell 32 00:02:24,140 --> 00:02:27,460 não usando funções anônimas para os callbacks, mas em vez disso, 33 00:02:27,460 --> 00:02:30,870 declarando essas funções com nomes específicos, 34 00:02:30,870 --> 00:02:35,630 e, em seguida, evitar a maneira como escrevemos o código como você viu aqui. 35 00:02:35,630 --> 00:02:41,190 Essa é uma das abordagens que as pessoas tomam para lidar com o problema do Callback Hell. 36 00:02:41,190 --> 00:02:44,990 Existem várias outras abordagens que foram sugeridas, 37 00:02:44,990 --> 00:02:51,085 links para alguns artigos a este respeito são fornecidos nos recursos adicionais. 38 00:02:51,085 --> 00:02:53,720 Mas nesta palestra em particular, 39 00:02:53,720 --> 00:02:56,810 vou me concentrar em uma abordagem particular que 40 00:02:56,810 --> 00:03:00,275 é usada para lidar com o problema do Inferno de Callback, 41 00:03:00,275 --> 00:03:02,370 que é o uso de promessas. 42 00:03:02,370 --> 00:03:07,345 Então podemos usar promessas para domar o problema do Inferno de Callback até certo ponto. 43 00:03:07,345 --> 00:03:12,200 Vamos olhar para como promessas nos ajudar a este respeito e 44 00:03:12,200 --> 00:03:17,180 no exercício vamos ver como, porque o driver NODE-MONGO DB já 45 00:03:17,180 --> 00:03:21,665 suporta uma interface proxy, podemos aproveitar isso para reescrever nosso código 46 00:03:21,665 --> 00:03:27,495 para aproveitar o suporte de promessa no driver MONGO DB. 47 00:03:27,495 --> 00:03:31,455 Resumindo brevemente o que é uma promessa. 48 00:03:31,455 --> 00:03:35,625 Uma promessa é um mecanismo que suporta computação assíncrona. 49 00:03:35,625 --> 00:03:39,250 Então, se você tem quantidade de trabalho que precisa ser feito, 50 00:03:39,250 --> 00:03:43,550 a promessa atua como um proxy para um valor que 51 00:03:43,550 --> 00:03:48,100 não é conhecido no momento, mas a promessa é dada a você. 52 00:03:48,100 --> 00:03:50,270 Mas quando o valor ficar disponível, 53 00:03:50,270 --> 00:03:53,225 ele estará disponível no futuro. 54 00:03:53,225 --> 00:03:56,690 Então a promessa representa um espaço reservado para esse valor. 55 00:03:56,690 --> 00:03:58,795 Se o valor resultar corretamente, 56 00:03:58,795 --> 00:04:02,240 então sua promessa resulta corretamente e você pode ter 57 00:04:02,240 --> 00:04:08,735 um pedaço de código executado a fim de lidar com o fato de que a promessa foi resolvida corretamente, 58 00:04:08,735 --> 00:04:12,950 se não, então você lida com o erro nessa situação. 59 00:04:12,950 --> 00:04:20,060 Assim, uma promessa resolverá ou em determinação ou rejeição da promessa. 60 00:04:20,060 --> 00:04:23,515 Uma promessa pendente pode resolver 61 00:04:23,515 --> 00:04:27,105 quando o valor é obtido corretamente, então, nesse caso, 62 00:04:27,105 --> 00:04:31,755 ela será resolvida ou o que chamamos de cumprimento da promessa. 63 00:04:31,755 --> 00:04:33,540 Então, quando a promessa for resolvida, 64 00:04:33,540 --> 00:04:35,960 então você terá um pedaço de código que 65 00:04:35,960 --> 00:04:38,760 lida com o fato de que a promessa foi resolvida. 66 00:04:38,760 --> 00:04:40,455 Se a promessa for rejeitada, 67 00:04:40,455 --> 00:04:43,985 você também deve lidar com essa situação 68 00:04:43,985 --> 00:04:48,470 a rejeição da promessa correspondentemente dentro do seu código. 69 00:04:48,470 --> 00:04:52,400 Portanto, essa é a razão pela qual sempre que você cria uma promessa, 70 00:04:52,400 --> 00:04:56,680 você fornece apenas as opções de resolução e rejeição a partir dela. 71 00:04:56,680 --> 00:05:02,905 A opção de resolução é tipicamente tratada pelo médico, em seguida, opção para a sua promessa. 72 00:05:02,905 --> 00:05:05,960 Então, por que usamos promessas? 73 00:05:05,960 --> 00:05:08,060 As promessas são usadas porque 74 00:05:08,060 --> 00:05:13,130 aborda o problema do inferno de retorno de chamada em grande medida e as promessas podem ser alteradas. 75 00:05:13,130 --> 00:05:15,860 Por exemplo, se você tiver uma promessa que, 76 00:05:15,860 --> 00:05:20,690 por sua vez, aciona uma chamada para outra que retornará uma promessa. 77 00:05:20,690 --> 00:05:26,525 O tratamento da promessa pode ser alterado para o identificador da promessa anterior. 78 00:05:26,525 --> 00:05:28,315 Então você pode ter um monte de, 79 00:05:28,315 --> 00:05:33,635 em seguida, chamadas que irá lidar com o retorno do valor. 80 00:05:33,635 --> 00:05:39,930 Agora vamos ver o uso disso no exercício que segue esta palestra. 81 00:05:39,930 --> 00:05:42,275 Para consumir uma promessa, 82 00:05:42,275 --> 00:05:47,675 você registrará uma função de retorno de chamada apropriada para 83 00:05:47,675 --> 00:05:50,810 quando o consumidor de uma promessa for notificado 84 00:05:50,810 --> 00:05:53,750 do cumprimento ou da rejeição da promessa. 85 00:05:53,750 --> 00:05:59,860 Assim, os retornos de chamada são registrados através do.then () para a promessa. 86 00:05:59,860 --> 00:06:07,040 Você usará o.catch () para detectar os erros dentro da promessa de retorno. 87 00:06:07,040 --> 00:06:09,845 Agora os métodos o.then () podem ser acorrentados 88 00:06:09,845 --> 00:06:15,205 juntos como você verá no exercício que se segue. 89 00:06:15,205 --> 00:06:19,730 Como exemplo, você normalmente lidaria com uma promessa 90 00:06:19,730 --> 00:06:26,250 encadeando.then () e o.catch () ao valor da promessa.