Dans cette conférence et l'exercice qui suit,
nous allons parler spécifiquement de Callback Hell.
Le problème qui se pose lorsque vous écrivez des
rappels dans le nœud et en particulier les rappels et le nœud imbriqués.
Nous allons également considérer les promesses comme une façon de résoudre le problème de l'enfer de rappel.
Pour vous donner une idée de ce que le problème typique de Callback Hell va entraîner,
nous allons revoir le fichier index.js de l'exercice précédent.
Comme je parlais de cela dans l'exercice précédent,
vous remarquez que pour chacune des opérations que nous effectuons,
l'opération suivante est incluse dans la fonction de rappel ici
et ainsi de suite jusqu'à ce que vous formiez une pyramide comme structure aller à nouveau.
Donc, vous voyez cette structure comme pyramide apparaissant dans votre code.
Maintenant, imaginez que vous devez effectuer plusieurs opérations imbriquées comme celle-ci,
votre code deviendra très bientôt,
très complexe, et pas si facile à déchiffrer.
Maintenant, c'est ce que dans le monde node.js,
ils appellent Callback Hell.
Il y a eu plusieurs façons d'atténuer le problème qui se pose.
Maintenant, vous pouvez complètement éviter cela en raison du fait
que vous avez certaines opérations qui doivent être
terminées avant que l'opération suivante puisse être lancée,
mais nous pouvons réorganiser le code de manière à atténuer ce problème.
Les promesses sont l'une de ces façons d'y remédier.
Donc, pour résumer ce que nous venons de discuter, le
code de rappel fortement imbriqué,
provoque le problème de Callback Hell et il
résulte de notre tendance à écrire des programmes de haut en bas.
Nous sommes toujours raccrochés avec notre façon séquentielle d'écrire du code et
nous voyons donc plus pratique d'écrire du code de haut en bas,
et de le regarder comme s'il s'exécutait dans cet ordre.
Maintenant, nous pouvons contourner le problème Callback Hell
en n'utilisant pas de fonctions anonymes pour les rappels, mais en
déclarant ces fonctions avec des noms spécifiques,
puis en évitant la façon dont nous écrivons le code comme vous l'avez vu ici.
C' est l'une des approches que les gens adoptent pour faire face au problème du Callback Hell.
Plusieurs autres approches ont été suggérées,
des liens vers quelques articles à cet égard sont fournis dans les ressources supplémentaires.
Mais dans cette conférence,
je vais me concentrer sur une approche particulière qui
est utilisée pour traiter le problème de l'enfer de Callback, à
savoir l'utilisation des promesses.
Donc, nous pouvons utiliser des promesses pour apprivoiser le problème de l'enfer de Callback dans une certaine mesure.
Nous allons voir comment les promesses nous aident à cet égard et dans
l'exercice, nous verrons comment, parce que le pilote NODE-MONGO DB
supporte déjà une interface proxy, nous pouvons tirer parti de cela
pour réécrire notre code pour profiter du support promis dans le pilote MONGO DB.
Résumer brièvement ce qu'est une promesse.
Une promesse est un mécanisme qui prend en charge le calcul asynchrone.
Donc, si vous avez beaucoup de travail à faire,
la promesse agit comme un proxy pour une valeur qui
n'est pas connue pour le moment mais la promesse vous est donnée.
Mais lorsque la valeur sera disponible,
elle sera disponible à l'avenir.
Donc, la promesse représente un espace réservé pour cette valeur.
Si la valeur aboutit correctement,
alors votre promesse aboutit correctement et vous pouvez faire
exécuter un morceau de code afin de gérer le fait que la promesse a été résolue correctement,
sinon vous gérez l'erreur dans cette situation.
Donc, une promesse se résoudra soit en résolution, soit en rejet de la promesse.
Une promesse en attente peut soit résoudre
lorsque la valeur est correctement obtenue, donc dans ce cas,
elle sera résolue ou ce que nous appelons comme la réalisation de la promesse.
Donc, lorsque la promesse est résolue,
alors vous aurez un morceau de code qui
gère le fait que la promesse a été résolue.
Si la promesse est rejetée,
vous devriez également gérer cette situation
le rejet de la promesse en conséquence dans votre code.
C' est donc la raison pour laquelle chaque fois que vous créez une promesse,
vous ne fournissez que les options de résolution et de rejet de celle-ci.
L' option de résolution est généralement gérée par le médecin puis option pour votre promesse.
Alors pourquoi utilisons-nous des promesses ?
Les promesses sont utilisées car il résout
le problème de l'enfer de rappel dans une large mesure et les promesses peuvent être modifiées.
Par exemple, si vous avez une promesse qui à
son tour déclenche un appel à une autre qui retournera une promesse.
La gestion de la promesse peut être changée à la poignée de la promesse précédente.
Ainsi, vous pouvez avoir un tas de,
puis des appels qui géreront le retour de la valeur.
Maintenant, nous allons voir l'utilisation de cela dans l'exercice qui suit cette conférence.
Pour consommer une promesse,
vous devez enregistrer une fonction de rappel appropriée
lorsque le consommateur d'une promesse est informé
de l'exécution ou du rejet de la promesse.
Donc, les rappels sont enregistrés via .then () à la promesse.
Vous utiliserez le fichier .catch () pour attraper les erreurs dans la promesse de retour.
Maintenant, les méthodes .then () peuvent être enchaînées
ensemble comme vous le verrez dans l'exercice qui suit.
Par exemple, vous géreriez normalement une promesse en
chaînant les .then () et .catch () à la valeur de promesse.