javascript - ¿Cuándo alguien necesitaría crear un diferido?

promise ecmascript-6

Question

En general, parece que ahora se desaconseja la creación de objetos diferidos a favor del uso del constructor Promise de estilo ES6. ¿Existe una situación en la que sería necesario (o mejor de alguna manera) usar un diferido?

Por ejemplo, en esta página , el siguiente ejemplo se da como justificación para usar un diferido:

function delay(ms) {
var deferred = Promise.pending();
setTimeout(function(){
deferred.resolve();
}, ms);
return deferred.promise;
}

Sin embargo, esto podría hacerse igual de bien con el constructor Promise:

function delay(ms) {
return new Promise(function(resolve, reject){
setTimeout(function(){
resolve();
}, ms);
});
}

Answer 1

¿Existe una situación en la que sería necesario (o mejor de alguna manera) usar un diferido?

No existe tal situación en la que sea necesario un aplazamiento. "Mejor" es una cuestión de opinión, así que no abordaré eso aquí.

Hay una razón por la cual la especificación de promesa ES6 no tiene un objeto diferido. Simplemente no necesitas uno. Cualquier cosa para la que la gente solía usar un objeto diferido siempre se puede hacer de otra manera que no use un objeto diferido.

En primer lugar, la mayoría de los usos encajan muy bien en el modelo de constructor de promesas. En segundo lugar, cualquier otro caso que no encajaba tan bien en ese modelo todavía se puede lograr con el constructor de la promesa o comenzando con una promesa resuelta y encadenándola.

El principal caso de uso que he visto para un diferido es cuando desea pasar la capacidad de resolve() o reject() a otra pieza de código que no sea el código que creó la promesa. Un diferido lo hizo muy fácil, ya que simplemente podía pasar el objeto diferido y tenía métodos públicos para resolverlo o rechazarlo. Pero, con una promesa, también puede pasar los métodos de resolve y / o reject . Dado que están vinculados al objeto específico automáticamente, puede pasar las referencias de función. Y, en otros casos, puede dejar que el otro código cree su propia promesa y lo resuelva / rechace por sí mismo y que esa operación se vincule con la suya en lugar de dejar que resuelvan / rechacen su promesa. ¿Es todo tan limpio como pasar un objeto diferido? Principalmente es una cuestión de opinión, pero tampoco son casos de uso muy comunes y todos son algo que se puede lograr sin un objeto diferido separado.

Y, como señala torazaburo, dejar que un código externo resuelva o rechace su promesa es un poco anti-patrón en sí mismo. Usted creó la promesa, la resuelve / rechaza. Si desea utilizar eventos externos para decidir cuándo resolverlo / rechazarlo, haga que le notifiquen (a través de su propia promesa o devolución de llamada) y puede resolver / rechazar su propia promesa. O haga que creen su propia promesa que puede usar. Ese es realmente el modelo deseado. O bien, déjelos encadenar a su promesa para que el resultado final esté determinado cuando se realice su operación.

Si uno estaba acostumbrado a codificar con el objeto diferido (por ejemplo, con un jQuery diferido), podría llevar un poco acostumbrarse a codificar sin él, pero después de un tiempo simplemente comienza a pensar de manera diferente y comienza a ser natural usarlo El constructor de la promesa.

Una vez que promete la esfera de las operaciones asíncronas que usa en cualquier aplicación, es bastante raro que alguna vez necesite crear sus propias promesas porque en su mayoría solo está construyendo promesas que las funciones asíncronas que llama ya están creando o usando operaciones de control de flujo como Promise.all() que crean grandes promesas para usted.

Este es el punto principal de los antipatrones. Use las promesas que ya se crearon para usted en lugar de crear manualmente más. Encadenarlos. Devuelva las promesas de los .then() para vincular las operaciones asíncronas bajo control lógico.

Por supuesto, hay operaciones asíncronas existentes que no devuelven promesas para las que alguien necesita crear una promesa, pero eso debe hacerse en una capa promisoria en algún lugar fuera del alcance de su lógica de codificación principal y solo una vez para esa operación y luego el código que llama a la operación asincrónica debería poder usar las promesas devueltas.

Answer 2

Native Promises no tiene todos los métodos integrados que diferidos tienen listos para usar, por ejemplo, el método para resolver la promesa fuera del alcance de su constructor (sin embargo, es muy fácil de implementar con Native Promise) y la capacidad de mire el estado de una promesa (que está oculto del JavaScript normal en las promesas nativas, aunque puede inspeccionarse en las herramientas de desarrollo).

La razón principal para usar diferido hoy sería la compatibilidad con el código que depende de esos métodos adicionales. Es difícil dar una respuesta definitiva a su pregunta sin pisar territorio de opinión.