C'è qualcosa che un 'Promise' può fare che 'async' non può?

Question

C'è qualcosa che un 'Promise' può fare che 'async' non può?

#1 da (4 voti)
#2 da (3 voti)

5

Recentemente, ho trascorso molto tempo a tentare di immergermi e comprendere le Promesse di Javascript, in particolare quelle che aderiscono alle Promesse / A + spec . Quello che sto cercando di capire è se Promises effettivamente offra agli sviluppatori strumenti aggiuntivi in particolare rispetto a async basato su CPS, o se è principalmente zucchero sintattico e uno strumento per ridurre la verbosità o semplificare alcuni comportamenti.

Un argomento che ho ascoltato per le promesse è la gestione degli errori. In tal caso, utilizzando la libreria async è molto facile eseguire un async.waterfall di funzioni, ognuna in attesa del precedente per il completamento, ognuna avvolta in un try / catch per gestire gli errori sincroni (poiché né Promises , né async gestisce gli errori asincroni), passando gli errori rilevati a un gestore degli errori. In tale situazione, Promises e async si comportano in modo identico per quanto riguarda la semantica degli errori ( sintesi che mostra questo comportamento ).

Un altro argomento che ho ascoltato per le promesse sono i metodi a prova di futuro che sono ora sincronizzati, ma in seguito asincroni. La teoria è che se la funzione restituisce una promessa, non importa cosa succederebbe se fosse modificata in seguito. Poiché sia il mittente che il destinatario devono essere modificati per aderire al contratto di promessa, non è possibile affermare lo stesso argomento per modificare sia il mittente che il destinatario per utilizzare il contratto CPS, anche se è sincrono, per verificarlo in futuro?

Quindi con questo in mente c'è un caso d'uso a cui puoi pensare che può essere risolto in modo ottimale solo da Promises o il loro utilizzo è davvero più un caso di preferenza e il desiderio di ridurre la verbosità e ridurre le possibilità di errore?

javascript

posta Nucleon 20.02.2014 - 06:35

fonte

2 risposte

Leggi altre domande sui tag javascript

Branch due volte per condizioni uniche "Pulisci codice": come organizzare le interrogazioni con nome?

score 4 · Answer 1

Alcuni dei vantaggi delle promesse sono che rendono le operazioni asincrone un'entità di "prima classe". Possono essere trasformati, sono componibili e il loro uso si traduce anche nella riduzione del nesting e nella gestione del codice asincrono più analogo al codice di sincronizzazione. Per me, di solito è più leggibile avere una catena di promesse di callback annidati. Molte lingue moderne sono passate allo stile promettente asincrono.

Vedi: link

score 3 · Answer 2

Credo che i due principali vantaggi di Promises sono:

Codice molto più leggibile che descrive chiaramente la sequenza di operazioni. Penso a "zucchero" come al salvataggio della tipizzazione o oscuramento della complessità (spesso magica), mentre in questo caso, ciò che è più saliente è fornire una maggiore chiarezza e quindi un codice più solido e meno soggetto a errori. Come ha detto Knuth, il codice è principalmente per gli esseri umani, e incidentalmente è eseguibile dai computer.
Possibilità di ignorare se un'operazione è già stata completata o meno al momento dell'esecuzione del codice chiamante. Questo è diverso da quello a prova di futuro, che significa essere agnostici al momento di scrivere il codice. Alcune implementazioni di Promise consentono di restituire gli oggetti promessi che hanno già già risolti ma che possono ancora chiamare then() . A volte si tratta di condizioni di gara altrimenti piacevoli.

Non ho esperienza profonda con loro, ma non credo che ci siano altri vantaggi significativi oltre a quelli sopra. Ma i vantaggi sopra riportati sono molto grandi.

L'unico svantaggio che ho incontrato è l'utilizzo di diverse librerie le cui implementazioni Promise hanno differenze sottili, come il comportamento di chiamare then () su una promessa già risolta. Anche il problema per cui la libreria A (ngluar, * cough *) poteva accettare oggetti promettenti in molti posti, ma usava la digitazione esplicita piuttosto che anatra, si entra in situazioni fastidiose in cui si deve avvolgere la promessa della biblioteca B con le promesse della biblioteca A , avendo l'effetto opposto dello zucchero. Questo è fondamentalmente un effetto collaterale di Javascript che non ha né Promises native né alcun meccanismo per una libreria standard, ma è un avvertimento del mondo reale.

Anche la terminologia è leggermente sciocca. Thenable?