Estaba escribiendo código que hace algo parecido a esto:

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() */ |     });
}                                        | }

Alguien me dijo que esto se llama " antipatrón diferido " o " Promiseantipatrón de constructor " respectivamente, ¿qué tiene de malo este código y por qué se llama antipatrón ?

El antipatrón diferido (ahora antipatrón de construcción explícita) acuñado por Esailija es un antipatrón común que son nuevos en las promesas, lo hice yo mismo cuando lo usé por primera vez. El problema con el código anterior es que no puede utilizar el hecho de que promete la cadena.

Las promesas pueden encadenarse .theny usted puede devolverlas directamente. Su código getStuffDonepuede reescribirse como:

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

Las promesas tienen que ver con hacer que el código asincrónico sea más legible y comportarse como un código sincrónico sin ocultar ese hecho. Las promesas representan una abstracción sobre un valor de operación de una sola vez, resumen la noción de una declaración o expresión en un lenguaje de programación.

Solo debe usar objetos diferidos cuando convierte una API a promesas y no puede hacerlo automáticamente, o cuando escribe funciones de agregación que se expresan más fácilmente de esta manera.

Citando a Esailija:

Este es el antipatrón más común. Es fácil caer en esto cuando realmente no comprende las promesas y piensa en ellas como emisores de eventos glorificados o utilidad de devolución de llamada. Recapitulemos: las promesas se tratan de hacer que el código asíncrono retenga la mayoría de las propiedades perdidas del código síncrono, como la sangría plana y un canal de excepción.

¿Qué tiene de malo?

¡Pero el patrón funciona!

Eres afortunado. Desafortunadamente, probablemente no, ya que es probable que hayas olvidado algunos casos extremos. En más de la mitad de los casos que he visto, el autor se ha olvidado de encargarse del controlador de errores:

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

Si se rechaza la otra promesa, esto pasará desapercibido en lugar de propagarse a la nueva promesa (donde se manejaría), y la nueva promesa permanece pendiente para siempre, lo que puede provocar fugas.

Lo mismo sucede en el caso de que su código de devolución de llamada provoque un error, por ejemplo, cuando resultno tiene un propertyy se produce una excepción. Eso no se manejaría y dejaría la nueva promesa sin resolver.

Por el contrario, el uso se .then()ocupa automáticamente de estos dos escenarios y rechaza la nueva promesa cuando ocurre un error:

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

El antipatrón diferido no solo es engorroso, sino también propenso a errores . Usar .then()para encadenar es mucho más seguro.

¡Pero he manejado todo!

De Verdad? Bueno. Sin embargo, esto será bastante detallado y abundante, especialmente si utiliza una biblioteca prometedora que admita otras funciones como la cancelación o el envío de mensajes. ¿O tal vez lo hará en el futuro, o desea cambiar su biblioteca por una mejor? No querrás volver a escribir tu código para eso.

Los métodos de las bibliotecas ( then) no solo admiten de forma nativa todas las características, sino que también pueden tener ciertas optimizaciones. Su uso probablemente acelerará su código, o al menos permitirá que se optimice en futuras revisiones de la biblioteca.

¿Cómo lo evito?

Por lo tanto, cada vez que se encuentre creando manualmente una Promiseo una Deferredpromesa existente, consulte primero la API de la biblioteca . El antipatrón diferido a menudo es aplicado por personas que ven las promesas [solo] como un patrón de observación, pero las promesas son más que devoluciones de llamada : se supone que son componibles. Cada biblioteca decente tiene muchas funciones fáciles de usar para la composición de promesas de todas las maneras imaginables, cuidando todas las cosas de bajo nivel con las que no desea lidiar.

Si ha encontrado la necesidad de componer algunas promesas de una nueva manera que no sea compatible con una función auxiliar existente, escribir su propia función con aplazamientos inevitables debería ser su última opción. Considere cambiar a una biblioteca más funcional y / o presente un error en su biblioteca actual. Su responsable de mantenimiento debería poder derivar la composición de las funciones existentes, implementar una nueva función auxiliar para usted y / o ayudar a identificar los casos límite que deben manejarse.