La différence entre le rappel asynchrone js Async/Await et Promise, 6 raisons pour lesquelles Async/Await remplace Promise

Ce chapitre vous présentera la différence entre Async/Await et Promise dans le rappel asynchrone js, et 6 raisons pour lesquelles Async/Await remplace Promise. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Qu'est-ce qu'Async/Await ?

async/await est une nouvelle façon d'écrire du code asynchrone. Les méthodes précédentes étaient des fonctions de rappel et Promise. .

async/await est implémenté sur la base de Promise et ne peut pas être utilisé pour les fonctions de rappel ordinaires.

Async/await, comme Promise, n'est pas bloquant.

async/await fait ressembler le code asynchrone à du code synchrone, ce qui est sa magie.

Syntaxe Async/Await

Dans l'exemple, la fonction getJSON renvoie une promesse, qui renverra un objet JSON lorsque la promesse sera résolue avec succès. Nous appelons simplement cette fonction, imprimons l'objet JSON renvoyé et renvoyons "done".

L'utilisation de Promise est comme ceci :

const makeRequest = () =>
  getJSON()
    .then(data => {
      console.log(data)
      return "done"
    })makeRequest()

L'utilisation d'Async/Await est comme ceci :

const makeRequest = async () => {
  console.log(await getJSON())
  return "done"}makeRequest()

Ils ont quelques légères différences :

Il y a un mot-clé aync supplémentaire devant la fonction. Le mot clé wait ne peut être utilisé que dans les fonctions définies par aync. La fonction asynchrone renverra implicitement une promesse, et la valeur de résolution de la promesse est la valeur du retour de la fonction. (La valeur reosolve dans l'exemple est la chaîne "done")

Le premier point implique que nous ne pouvons pas utiliser wait dans le code le plus externe car il ne fait pas partie de la fonction async.

// 不能在最外层代码中使用
awaitawait makeRequest()
// 这是会出事情的 
makeRequest().then((result) => {
  // 代码
 })

await getJSON() signifie que console.log attendra que la promesse de getJSON soit résolue avec succès avant de l'exécuter.

Pourquoi Async/Await est-il meilleur ?

1. Simplicité

Comme le montre l'exemple, l'utilisation d'Async/Await permet évidemment d'économiser beaucoup de code. Nous n'avons pas besoin d'écrire .then, nous n'avons pas besoin d'écrire de fonctions anonymes pour gérer la valeur de résolution de Promise, nous n'avons pas besoin de définir des variables de données redondantes et nous évitons le code imbriqué. Ces petits avantages s’additionnent rapidement, comme cela deviendra plus évident dans les exemples de code qui suivent.

2. Gestion des erreurs

Async/Await permet à try/catch de gérer les erreurs synchrones et asynchrones. Dans l'exemple de promesse ci-dessous, try/catch ne peut pas gérer l'erreur JSON.parse car elle se trouve à l'intérieur de la promesse. Nous devons utiliser .catch pour que le code de gestion des erreurs soit très redondant. De plus, notre code de production actuel sera plus compliqué.

const makeRequest = () => {
  try {
    getJSON()
      .then(result => {
        // JSON.parse可能会出错
        const data = JSON.parse(result)
        console.log(data)
      })
      // 取消注释，处理异步代码的错误
      // .catch((err) => {
      //   console.log(err)
      // })
  } catch (err) {
    console.log(err)
  }}

Si aync/await est utilisé, catch peut gérer les erreurs JSON.parse :

const makeRequest = async () => {
  try {
    // this parse may fail
    const data = JSON.parse(await getJSON())
    console.log(data)
  } catch (err) {
    console.log(err)
  }}

Instruction conditionnelle

Dans l'exemple suivant, les données ont besoin. à obtenir, puis décidez si vous souhaitez revenir directement ou continuer à obtenir plus de données en fonction des données renvoyées. ·

const makeRequest = () => {
  return getJSON()
    .then(data => {
      if (data.needsAnotherRequest) {
        return makeAnotherRequest(data)
          .then(moreData => {
            console.log(moreData)
            return moreData          })
      } else {
        console.log(data)
        return data      }
    })}

Ces codes me donnent mal à la tête rien qu'en les regardant. Il est facile de se tromper avec les instructions d'imbrication (6 niveaux), de parenthèses et de retour qui doivent simplement transmettre le résultat final à la promesse la plus externe.

Le code ci-dessus est écrit en utilisant async/await, ce qui peut grandement améliorer la lisibilité :

const makeRequest = async () => {
  const data = await getJSON()
  if (data.needsAnotherRequest) {
    const moreData = await makeAnotherRequest(data);
    console.log(moreData)
    return moreData  } else {
    console.log(data)
    return data    
  }}

4 Valeurs intermédiaires

Vous avez probablement rencontré un tel scénario, appelez promise1. , utilisez le résultat renvoyé par promise1 pour appeler promise2, puis utilisez les résultats des deux pour appeler promise3. Votre code ressemblera probablement à ceci :

const makeRequest = () => {
  return promise1()
    .then(value1 => {
      return promise2(value1)
        .then(value2 => {        
          return promise3(value1, value2)
        })
    })}

Si promise3 ne nécessite pas de valeur1, vous pouvez simplement imbriquer les promesses à plat. Si vous ne supportez pas l'imbrication, vous pouvez mettre les valeurs 1 et 2 dans Promise.all pour éviter une imbrication profonde :

const makeRequest = () => {
  return promise1()
    .then(value1 => {
      return Promise.all([value1, promise2(value1)])
    })
    .then(([value1, value2]) => {      
      return promise3(value1, value2)
    })}

Cette approche sacrifie la sémantique pour la lisibilité. Il n'y a aucune raison de mettre value1 et value2 dans un tableau autre que pour éviter l'imbrication.

Si vous utilisez async/await, le code deviendra extrêmement simple et intuitif.

const makeRequest = async () => {
  const value1 = await promise1()
  const value2 = await promise2(value1)
  return promise3(value1, value2)}

5. Pile d'erreurs

Dans l'exemple suivant, plusieurs promesses sont appelées, en supposant qu'une erreur est générée quelque part dans la chaîne de promesses :

const makeRequest = () => {
  return callAPromise()
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => {
      throw new Error("oops");
    })}makeRequest()
  .catch(err => {
    console.log(err);
    // output
    // Error: oops at callAPromise.then.then.then.then.then (index.js:8:13)
  })

Le la pile d'erreurs renvoyée dans la chaîne Promise ne donne aucune idée de l'endroit où l'erreur s'est produite. Pire encore, c'est trompeur : la seule fonction dans la pile d'erreurs s'appelle callAPromise, ce qui n'a rien à voir avec l'erreur. (Le nom du fichier et le numéro de ligne sont toujours utiles).

Cependant, la pile d'erreurs dans async/await pointera vers la fonction où se trouve l'erreur :

const makeRequest = async () => {
  await callAPromise()
  await callAPromise()
  await callAPromise()
  await callAPromise()
  await callAPromise()
  throw new Error("oops");}makeRequest()
  .catch(err => {
    console.log(err);
    // output
    // Error: oops at makeRequest (index.js:7:9)
  })

Dans un environnement de développement, cet avantage n'est pas grand. Cependant, cela vous sera très utile lorsque vous analyserez le journal des erreurs de l’environnement de production. À ce stade, il est préférable de savoir que l'erreur s'est produite dans makeRequest plutôt que de savoir que l'erreur s'est produite dans la chaîne then.

6. Débogage

Le dernier point très important est que async/await peut faciliter le débogage du code. 2 raisons pour lesquelles le débogage des promesses est pénible :

1) Vous ne pouvez pas définir de points d'arrêt dans les fonctions fléchées qui renvoient des expressions

2) Si vous définissez un point d'arrêt dans le bloc de code .then et utilisez la touche de raccourci Step Over. Le débogueur ne passera pas au bloc de code .then suivant car il ignorera uniquement le code asynchrone.

Lorsque vous utilisez wait/async, vous n'avez plus besoin d'autant de fonctions fléchées, vous pouvez donc ignorer les instructions wait tout comme le débogage du code synchrone

Conclusion

Async/Await est l'une des fonctionnalités les plus révolutionnaires ajoutées à JavaScript ces dernières années. Cela vous fera réaliser à quel point la syntaxe Promise est mauvaise et vous fournira une alternative intuitive.

Inquiétude

Peut-être avez-vous des doutes légitimes sur Async/Await :
Cela rend le code asynchrone moins évident : nous sommes habitués à utiliser des fonctions de rappel ou .then pour identifier le code asynchrone, et cela peut nous prendre plusieurs semaines pour nous habituer au nouvel indicateur. Cependant, C# dispose de cette fonctionnalité depuis de nombreuses années, et les amis qui la connaissent devraient savoir que cet inconvénient temporaire en vaut la peine.
Node 7 n'est pas une LTS (long-term support release) : cependant, Node 8 sortira le mois prochain, et migrer votre code vers la nouvelle version sera très simple.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!