En esta conferencia y el ejercicio que sigue,
hablaremos específicamente de Callback Hell.
El problema que surge cuando se escriben
devoluciones de llamada en el nodo y especialmente las devoluciones de llamada anidadas y el nodo.
También veremos las promesas como una forma de abordar el problema del infierno de devolución de llamada.
Para darle una idea de lo que resultará el típico problema del infierno de devolución de llamada,
volvamos a visitar el archivo index.js del ejercicio anterior.
Como estaba hablando de ello en el ejercicio anterior,
usted nota que para cada una de las operaciones que realizamos,
la operación posterior se incluye dentro de la función de devolución de llamada aquí
y así sucesivamente hasta que se forma una estructura pirámide como ir de nuevo.
Así que ves esta estructura como pirámide surgiendo dentro de tu código.
Ahora imagine que necesita realizar múltiples operaciones anidadas como esta,
su código se volverá muy pronto,
muy complejo y no tan fácil de descifrar.
Ahora bien, esto es a lo que en el mundo node.js,
se refieren como Callback Hell.
Ha habido varias formas de mitigar el problema que se plantea.
Ahora puede evitarlo por completo debido al hecho de
que tiene ciertas operaciones que deben
completarse antes de que se pueda iniciar la siguiente operación,
pero podemos reorganizar el código de una manera que mitigue este problema.
Las promesas son una de esas formas de abordar esto.
Entonces, para resumir lo que acabamos de discutir, el
código de devolución de llamada fuertemente anidado,
causa el problema del infierno de devolución de llamada y
resulta de nuestra tendencia a escribir programas de arriba hacia abajo.
Todavía estamos colgados con nuestra forma secuencial de escribir código y
por lo tanto vemos que es más conveniente escribir código de arriba a abajo,
y mirarlo como si se estuviera ejecutando en ese orden.
Ahora podemos solucionar el problema del infierno de devolución de llamada al
no usar funciones anónimas para las devoluciones de llamada, sino
declarar esas funciones con nombres específicos,
y luego evitar la forma en que escribimos el código como vio aquí.
Ese es uno de los enfoques que la gente toma para lidiar con el problema del infierno de devolución de llamada.
Hay varios otros enfoques que se han sugerido,
los enlaces a un par de artículos a este respecto se proporcionan en los recursos adicionales.
Pero en esta conferencia en particular,
me concentraré en un enfoque particular que
se utiliza para tratar el problema del infierno de devolución de llamada,
que es el uso de promesas.
Así que podemos usar promesas para domar el problema del infierno de devolución de llamada hasta cierto punto.
Vamos a ver cómo las promesas nos ayudan en este sentido y en
el ejercicio veremos cómo debido a que el controlador NODE-MONGO DB ya
soporta una interfaz proxy podemos aprovechar eso para reescribir nuestro código
para aprovechar el soporte prometido en el controlador MONGO DB.
Resumiendo brevemente lo que es una promesa.
Una promesa es un mecanismo que admite el cálculo asíncrono.
Así que si usted tiene la cantidad de trabajo que debe hacerse,
la promesa actúa como un proxy para un valor que
no se conoce en este momento, pero la promesa es dada a usted.
Pero cuando el valor esté disponible,
estará disponible en el futuro.
Por lo tanto, la promesa representa un marcador de posición para ese valor.
Si el valor resulta correctamente,
entonces su promesa resulta correctamente y puede hacer que se
ejecute un fragmento de código para manejar el hecho de que la promesa se resolvió correctamente,
si no, entonces maneja el error en esa situación.
Por lo tanto, una promesa se resolverá en resolución o en rechazo de la promesa.
Una promesa pendiente podría resolverse
cuando el valor se obtiene correctamente, por lo que en ese caso,
resolverá o lo que llamamos el cumplimiento de la promesa.
Entonces, cuando la promesa se resuelva,
entonces tendrá un fragmento de código que
maneja el hecho de que la promesa se ha resuelto.
Si la promesa es rechazada,
también debe manejar esa situación
el rechazo de la promesa correspondientemente dentro de su código.
Así que esa es la razón por la que cada vez
que crea una promesa, solo proporciona las opciones de resolución y rechazo de ella.
La opción de resolución suele ser manejada por el médico y luego la opción para su promesa.
Entonces, ¿por qué usamos promesas?
Las promesas se usan porque aborda
el problema del infierno de devolución de llamada en gran medida y las promesas se pueden cambiar.
Por ejemplo, si tiene una promesa que a
su vez desencadena una llamada a otra que devolverá una promesa.
El manejo de la promesa se puede cambiar al mango de la promesa anterior.
Por lo tanto, puede tener un montón de,
luego llamadas que manejarán el retorno del valor.
Ahora veremos el uso de esto en el ejercicio que sigue a esta conferencia.
Para consumir una promesa,
registrará una función de devolución
de llamada adecuada para cuando se notifique al consumidor
de una promesa el cumplimiento o el rechazo de la promesa.
Entonces, las devoluciones de llamada se registran a través de.then () a la promesa.
Utilizará el.catch () para detectar los errores dentro de la promesa de devolución.
Ahora los métodos.then () se pueden
encadenar juntos como verá en el ejercicio que sigue.
Como ejemplo, normalmente manejaría una promesa
encadenando el.then () y el.catch () al valor de promesa.