Qual è la differenza tra le promesse JavaScript e l'attesa asincrona?

Ho già utilizzato le funzionalità ECMAScript 6 ed ECMAScript 7 (grazie a Babel) nelle mie applicazioni, sia mobili che web.

Il primo passo ovviamente è stato quello di ECMAScript 6 livelli. Ho imparato molti schemi asincroni, le promesse (che sono davvero promettenti), i generatori (non so perché il simbolo *), ecc. Da questi, le promesse si adattavano abbastanza bene al mio scopo. E li ho usati parecchio nelle mie applicazioni.

Ecco un esempio / pseudocodice di come ho implementato una promessa di base-

var myPromise = new Promise(
    function (resolve,reject) {
      var x = MyDataStore(myObj);
      resolve(x);
    });

myPromise.then(
  function (x) {
    init(x);
});

Col passare del tempo, mi sono imbattuto nelle funzionalità di ECMAScript 7 e una di queste è ASYNCe AWAITparole chiave / funzioni. Questi insieme fanno grandi meraviglie. Ho iniziato a sostituire alcune delle mie promesse con async & await. Sembrano aggiungere un grande valore allo stile di programmazione.

Di nuovo, ecco uno pseudocodice di come appare la mia funzione async, wait-

async function myAsyncFunction (myObj) {
    var x = new MyDataStore(myObj);
    return await x.init();
}
var returnVal = await myAsyncFunction(obj);

Tenendo da parte gli errori di sintassi (se presenti), entrambi fanno esattamente la stessa cosa, è quello che sento. Sono quasi riuscito a sostituire la maggior parte delle mie promesse con async, attende.

Perché è necessario async, wait quando le promesse fanno un lavoro simile?

Async, attende risolve un problema più grande? O era solo una soluzione diversa per richiamare l'inferno?

Come ho detto prima, sono in grado di usare promesse e asincrono, aspetto di risolvere lo stesso problema. C'è qualcosa di specifico che l'asincronia attende risolto?

Note aggiuntive:

Ho utilizzato ampiamente async, attende e promette nei miei progetti React e nei moduli Node.js. React in particolare è stato un early bird e ha adottato molte funzionalità ECMAScript 6 ed ECMAScript 7.

Perché è necessario async, wait quando Promises fa un lavoro simile? Async, attende risolve un problema più grande?

async/awaitti dà semplicemente una sensazione sincrona al codice asincrono. È una forma molto elegante di zucchero sintattico.

Per query semplici e manipolazione dei dati, Promises può essere semplice, ma se ti imbatti in scenari in cui è presente una manipolazione complessa dei dati e quant'altro, è più facile capire cosa sta succedendo se il codice sembra semplicemente sincrono (per dirla in un altro modo, la sintassi in sé e per sé è una forma di "complessità incidentale" che async/awaitpuò aggirare).

Se sei interessato a sapere, puoi usare una libreria come co(insieme ai generatori) per dare lo stesso tipo di sensazione. Cose come questa sono state sviluppate per risolvere il problema che alla async/awaitfine risolve (nativamente).

Async / Await fornisce una sintassi molto migliore in scenari più complessi. In particolare, tutto ciò che ha a che fare con i loop o con certi altri costrutti come try/ catch.

Per esempio:

while (!value) {
  const intermediate = await operation1();
  value = await operation2(intermediate);
}

Questo esempio sarebbe notevolmente più complicato usando solo Promises.

Perché è necessario async, wait quando Promises fa un lavoro simile? Async, attende risolve un problema più grande? o era solo una soluzione diversa per richiamare l'inferno? Come ho detto prima, sono in grado di utilizzare Promises e Async, Await per risolvere lo stesso problema. C'è qualcosa di specifico che Async Await ha risolto?

Le prime cose che devi capire che async/ awaitsyntax è solo zucchero sintattico che ha lo scopo di aumentare le promesse. In effetti il ​​valore di ritorno di una asyncfunzione è una promessa. async/ awaitsyntax ci dà la possibilità di scrivere in modo asincrono in modo sincrono. Ecco un esempio:

Promessa di concatenamento:

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

Async funzione:

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

Nell'esempio precedente, awaitattende che la promessa ( fetch(url)) venga risolta o rifiutata. Se la promessa viene risolta, il valore viene memorizzato nella responsevariabile e se la promessa viene rifiutata genera un errore e quindi entra nel catchblocco.

Possiamo già vedere che l'uso di async/ awaitpotrebbe essere più leggibile del concatenamento di promesse. Ciò è particolarmente vero quando la quantità di promesse che stiamo utilizzando aumenta. Sia Promise chaining che async/ awaitrisolvono il problema dell'inferno di callback e il metodo scelto dipende dalle preferenze personali.

Confronto completo con pro e contro.

JavaScript normale

• Professionisti

• Non richiede alcuna libreria o tecnologia aggiuntiva
• O ff re le migliori prestazioni
• Fornisce il miglior livello di compatibilità con le librerie di terze parti
• Consente la creazione di algoritmi ad hoc e più avanzati

• Contro

• Potrebbe richiedere codice extra e algoritmi relativamente complessi

Async (libreria)

• Professionisti

• Semplifica i modelli di flusso di controllo più comuni
• È ancora una soluzione basata su callback
• Buona performance

• Contro

• Introduce una dipendenza esterna
• Potrebbe ancora non essere sufficiente per i flussi avanzati

Promesse

• Professionisti

• Semplifica notevolmente i modelli di flusso di controllo più comuni
• Robusta gestione degli errori
• Parte della speci fi ca ES2015
• Garantisce l'invocazione differita di onFulfilled e onRejected

• Contro

• Richiede API basate su callback promesse
• Introduce un piccolo successo in termini di prestazioni

Generatori

• Professionisti

• Rende l'API non bloccante come un'API di blocco
• Semplifica la gestione degli errori
• Parte delle speci fi che ES2015

• Contro

• Richiede una libreria di flusso di controllo complementare
• Richiede ancora callback o promesse di implementare flussi non sequenziali
• Richiede thunkify o promettere API non basate su generatore

Async attende

• Professionisti

• Fa sembrare l'API non bloccante un blocco
• Sintassi pulita e intuitiva

• Contro

• Richiede Babel o altri transpilers e alcune configurazioni da utilizzare oggi

Async / await può aiutare a rendere il codice più pulito e più leggibile nei casi in cui è necessario un flusso di controllo complicato. Produce anche codice più adatto al debug. E consente di gestire errori sia sincroni che asincroni con appena try/catch.

Recentemente ho scritto questo post che mostra i vantaggi di async / await rispetto alle promesse in alcuni casi d'uso comuni con esempi di codice: 6 motivi per cui JavaScript Async / Await Blows Promises Away (Tutorial)