Promesa: ¿es posible forzar la cancelación de una promesa?

En JavaScript moderno, no

Las promesas se han cumplido (ja) y parece que nunca será posible cancelar una promesa (pendiente).

En su lugar, existe una primitiva de cancelación multiplataforma (nodo, navegadores, etc.) como parte de WHATWG (un organismo de estándares que también crea HTML) llamada AbortController. Puedes usarlo para cancelar funciones que devuelven promesas en lugar de promesas mismas:

// Take a signal parameter in the function that needs cancellation
async function somethingIWantToCancel({ signal } = {}) {
  // either pass it directly to APIs that support it
  // (fetch and most Node APIs do)
  const response = await fetch('.../', { signal });
  // return response.json;

  // or if the API does not already support it -
  // manually adapt your code to support signals:
  const onAbort = (e) => {
    // run any code relating to aborting here
  };
  signal.addEventListener('abort', onAbort, { once: true });
  // and be sure to clean it up when the action you are performing
  // is finished to avoid a leak
  // ... sometime later ...
  signal.removeEventListener('abort', onAbort);
}

// Usage
const ac = new AbortController();
setTimeout(() => ac.abort(), 1000); // give it a 1s timeout
try {
  await somethingIWantToCancel({ signal: ac.signal });
} catch (e) {
  if (e.name === 'AbortError') {
    // deal with cancellation in caller, or ignore
  } else {
    throw e; // don't swallow errors :)
  }
}

No. No podemos hacer eso todavía.

Las promesas de ES6 aún no admiten la cancelación . Está en camino y su diseño es algo en lo que mucha gente trabajó muy duro. La semántica de cancelación de sonido es difícil de lograr y esto es un trabajo en progreso. Hay debates interesantes sobre el repositorio "fetch", sobre esdiscuss y sobre varios otros repositorios de GH, pero tendría paciencia si fuera usted.

Pero, pero, pero... ¡la cancelación es realmente importante!

Lo es, la realidad del asunto es que la cancelación es realmente un escenario importante en la programación del lado del cliente. Los casos que usted describe, como la cancelación de solicitudes web, son importantes y están en todas partes.

Entonces... ¡el idioma me jodió!

Sí, lo siento por eso. Las promesas tenían que llegar primero antes de que se especificaran más cosas, por lo que entraron sin algunas cosas útiles como .finallyy .cancel, aunque está en camino hacia la especificación a través del DOM. La cancelación no es una ocurrencia tardía, es solo una limitación de tiempo y un enfoque más iterativo para el diseño de API.

¿Entonces Que puedo hacer?

Tienes varias alternativas:

• Utilice una biblioteca de terceros como bluebird , que puede moverse mucho más rápido que la especificación y, por lo tanto, tener cancelación y muchas otras ventajas; esto es lo que hacen las grandes empresas como WhatsApp.
• Pasar un token de cancelación .

Usar una biblioteca de terceros es bastante obvio. En cuanto a un token, puedes hacer que tu método tome una función y luego la llame, como tal:

function getWithCancel(url, token) { // the token is for cancellation
   var xhr = new XMLHttpRequest;
   xhr.open("GET", url);
   return new Promise(function(resolve, reject) {
      xhr.onload = function() { resolve(xhr.responseText); });
      token.cancel = function() {  // SPECIFY CANCELLATION
          xhr.abort(); // abort request
          reject(new Error("Cancelled")); // reject the promise
      };
      xhr.onerror = reject;
   });
};

Lo que te permitiría hacer:

var token = {};
var promise = getWithCancel("/someUrl", token);

// later we want to abort the promise:
token.cancel();

Su caso de uso real:last

Esto no es demasiado difícil con el enfoque simbólico:

function last(fn) {
    var lastToken = { cancel: function(){} }; // start with no op
    return function() {
        lastToken.cancel();
        var args = Array.prototype.slice.call(arguments);
        args.push(lastToken);
        return fn.apply(this, args);
    };
}

Lo que te permitiría hacer:

var synced = last(getWithCancel);
synced("/url1?q=a"); // this will get canceled 
synced("/url1?q=ab"); // this will get canceled too
synced("/url1?q=abc");  // this will get canceled too
synced("/url1?q=abcd").then(function() {
    // only this will run
});

Y no, las bibliotecas como Bacon y Rx no "brillan" aquí porque son bibliotecas observables, simplemente tienen la misma ventaja que tienen las bibliotecas de promesas a nivel de usuario al no estar sujetas a especificaciones. Supongo que esperaremos para ver en ES2016 cuándo los observables se vuelven nativos. Sin embargo , son ingeniosos para escribir con anticipación.

May 14 '2015 10:05 Benjamin Gruenbaum