Stavo scrivendo un codice che fa qualcosa che assomiglia a:

function getStuffDone(param) {           | function getStuffDone(param) {
    var d = Q.defer(); /* or $q.defer */ |     return new Promise(function(resolve, reject) {
    // or = new $.Deferred() etc.        |     // using a promise constructor
    myPromiseFn(param+1)                 |         myPromiseFn(param+1)
    .then(function(val) { /* or .done */ |         .then(function(val) {
        d.resolve(val);                  |             resolve(val);
    }).catch(function(err) { /* .fail */ |         }).catch(function(err) {
        d.reject(err);                   |             reject(err);
    });                                  |         });
    return d.promise; /* or promise() */ |     });
}                                        | }

Qualcuno mi ha detto che questo si chiama rispettivamente " antipattern differito " o " Promiseantipattern costruttore ", cosa c'è di male in questo codice e perché viene chiamato antipattern ?

L' antipasto differito (ora anti-modello di costruzione esplicita) coniato da Esailija è un comune anti-modello che le persone che non conoscono le promesse fanno, l'ho fatto da solo quando ho usato le promesse. Il problema con il codice sopra è che non riesce a utilizzare il fatto che promette la catena.

Le promesse possono essere .thencollegate e puoi restituire direttamente le promesse. Il tuo codice in getStuffDonepuò essere riscritto come:

function getStuffDone(param){
    return myPromiseFn(param+1); // much nicer, right?
}

Le promesse riguardano il rendere il codice asincrono più leggibile e comportarsi come un codice sincrono senza nascondere questo fatto. Le promesse rappresentano un'astrazione rispetto al valore di una volta sola operazione, astraggono la nozione di una dichiarazione o espressione in un linguaggio di programmazione.

Dovresti usare oggetti differiti solo quando stai convertendo un'API in promesse e non puoi farlo automaticamente, o quando scrivi funzioni di aggregazione che sono più facili espresse in questo modo.

Citando Esailija:

Questo è l'anti-pattern più comune. È facile cadere in questo quando non capisci davvero le promesse e le pensi come emettitori di eventi glorificati o utilità di callback. Ricapitolando: le promesse riguardano il mantenimento del codice asincrono nella maggior parte delle proprietà perse del codice sincrono come l'indentazione piatta e un canale di eccezione.

Che cosa c'è che non va?

Ma il modello funziona!

Sei fortunato. Sfortunatamente, probabilmente non lo è, come probabilmente hai dimenticato un caso limite. In più della metà delle occorrenze che ho visto, l'autore ha dimenticato di occuparsi del gestore degli errori:

return new Promise(function(resolve) {
    getOtherPromise().then(function(result) {
        resolve(result.property.example);
    });
})

Se l'altra promessa viene respinta, ciò accadrà inosservato invece di essere propagato alla nuova promessa (dove verrebbe gestita) - e la nuova promessa rimane in sospeso per sempre, il che può causare perdite.

La stessa cosa accade nel caso in cui il codice di callback provochi un errore, ad esempio quando resultnon propertyè presente un'eccezione. Ciò non verrebbe gestito e lascerebbe irrisolta la nuova promessa.

Al contrario, l'utilizzo si .then()occupa automaticamente di entrambi questi scenari e rifiuta la nuova promessa quando si verifica un errore:

 return getOtherPromise().then(function(result) {
     return result.property.example;
 })

L'antipasto differito non è solo ingombrante, ma anche soggetto a errori . L'uso .then()per il concatenamento è molto più sicuro.

Ma ho gestito tutto!

Veramente? Buona. Tuttavia, questo sarà abbastanza dettagliato e abbondante, soprattutto se si utilizza una libreria promessa che supporta altre funzionalità come la cancellazione o il passaggio di messaggi. O forse lo farà in futuro, o vuoi scambiare la tua libreria con una migliore? Non vorrai riscrivere il tuo codice per questo.

I metodi delle librerie ( then) non solo supportano nativamente tutte le funzionalità, ma potrebbero anche avere determinate ottimizzazioni. Il loro utilizzo renderà probabilmente il tuo codice più veloce o almeno consentirà di essere ottimizzato da future revisioni della libreria.

Come lo evito?

Quindi, ogni volta che ti ritrovi a creare manualmente una Promiseo Deferrede già esistenti promesse, controlla prima l'API della libreria . L'antipasto differito viene spesso applicato da persone che vedono le promesse [solo] come un modello di osservatore - ma le promesse sono più che richiami : dovrebbero essere compostabili. Ogni biblioteca decente ha molte funzioni facili da usare per la composizione delle promesse in ogni modo pensabile, prendendosi cura di tutte le cose di basso livello che non vuoi affrontare.

Se hai trovato la necessità di comporre alcune promesse in un modo nuovo che non è supportato da una funzione di aiuto esistente, scrivere la tua funzione con inevitabili rinvii dovrebbe essere l'ultima opzione. Considera di passare a una libreria più ricca di funzionalità e / o di presentare un bug sulla tua libreria corrente. Il suo manutentore dovrebbe essere in grado di derivare la composizione dalle funzioni esistenti, implementare una nuova funzione di supporto per l'utente e / o aiutare a identificare i casi limite che devono essere gestiti.