Quelle est la différence entre JavaScript promesses et async attendent?

Pourquoi est asynchrone,attendent nécessaire quand les Promesses ne travail similaire? Ne async,attendent résoudre un problème plus grave?

async/await simplement vous donne un synchrones sensation de code asynchrone. Il est très élégante, une forme de sucre syntaxique.

Pour les requêtes simples et de manipulation de données, des Promesses peut être simple, mais si vous exécutez en est-il des scénarios complexes de manipulation de données et autres joyeusetés, il est plus facile de comprendre ce qu'il se passe si le code semble comme si elle synchrone (pour le dire d'une autre façon, de syntaxe et de lui-même est une forme de "accessoires de la complexité" qui async/await pouvez vous déplacer).

Si vous êtes intéressé à savoir, vous pouvez utiliser une bibliothèque comme co (à côté de générateurs) pour donner le même genre de sensation. Les choses de ce genre ont été mis au point pour résoudre le problème que async/await en fin de compte résout (nativement).

Ma question est, Pourquoi est asynchrone,attendent nécessaire lorsque les Promesses n'
emploi similaire? Ne async,attendent résoudre un problème plus grave? ou était-ce juste un
autre solution pour rappel l'enfer? Comme je l'ai dit précédemment, je suis en mesure de
utiliser des Promesses et Asynchrone,vous Attendent afin de résoudre le même problème. Est-il
rien de spécifique qu'Async Attendent-ils résolus?

La première chose que vous devez comprendre que async/await syntaxe est juste sucre syntaxique qui est destiné à augmenter promesses. En fait, la valeur de retour d'une async fonction est une promesse. async/await syntaxe nous donne la possibilité de l'écriture asynchrone en mode synchrone. Voici un exemple:

Promesse chaîne:

function logFetch(url) {
  return fetch(url)
    .then(response => response.text())
    .then(text => {
      console.log(text);
    }).catch(err => {
      console.error('fetch failed', err);
    });
}

Async fonction:

async function logFetch(url) {
  try {
    const response = await fetch(url);
    console.log(await response.text());
  }
  catch (err) {
    console.log('fetch failed', err);
  }
}

Dans l'exemple ci-dessus le await attend la promesse (fetch(url)) d'être résolue ou rejeté. Si la promesse est résolu valeur est stockée dans la response variable, si la promesse est rejetée, il lancerait une erreur et ainsi entrer dans le catch bloc.

Nous pouvons déjà voir que l'utilisation de async/await peut être plus lisible que la promesse de chaînage. Cela est particulièrement vrai lorsque le montant des promesses dont nous sommes l'aide augmente. À la fois Promesse de chaînage et async/await résoudre le problème de rappel de l'enfer et de la méthode que vous choisissez est question de préférence personnelle.

Comparaison avec des avantages et des inconvénients.

Plaine JavaScript

• Pros

• Ne nécessite pas d'autres bibliothèques ou de la technologie
• Offre les meilleures performances
• Offre le meilleur niveau de compatibilité avec les bibliothèques de tiers
• Permet la création ad hoc, et de plus en plus avancé des algorithmes de

• Contre

• Peut nécessiter un code supplémentaire et relativement complexes algorithmes de

Async (bibliothèque)

• Pros

• Simplifie les plus courantes modèles de flux de contrôle
• Est toujours un rappel à base de solution
• De bonnes performances

• Contre

• Introduit une dépendance externe
• Peut-être pas encore assez avancé pour les flux de

Promesses

• Pros

• Simplifie grandement le plus commun des modèles de flux de contrôle
• Robuste de gestion des erreurs
• Partie de la ES2015 spécification
• Garanties différés invocation de onFulfilled et onRejected

• Contre

• Nécessite promisify rappel des Api en fonction de
• Introduit un petit gain de performance

Générateurs

• Pros

• Fait de non-blocage de l'API de ressembler à un blocage d'un
• Simplifie la gestion des erreurs
• Partie de ES2015 spécification

• Contre

• Nécessite un complément de flux de contrôle de la bibliothèque
• Nécessite encore des rappels ou promet de mettre en œuvre les non-séquentielle des flux de
• Nécessite thunkify ou promisify nongenerator Api en fonction de

Async attendent

• Pros

• Fait de non-blocage de l'API regarder comme le blocage de
• Propre et intuitive syntaxe

• Contre

• Nécessite Babel ou d'autres transpilers et un peu de configuration à être utilisé aujourd'hui