2014-02-08 8 views
13

Ich verwende die Q-Bibliothek, die die Promise-Spezifikation gut unterstützt. Aber ich versuche auch, die Promise-Klasse zu verwenden, die vor kurzem in Chrome implementiert wurde (experimentell).JavaScript Promise/Defer in Chrome

Es gibt die Defer-Funktion in Q, die zum Erstellen eines nicht erfüllten Versprechens verwendet werden kann, das in Zukunft aufgelöst oder zurückgewiesen werden kann.

Ich habe die gleiche Funktionalität mit dem nativen Promise in Chrome vorgestellt implementiert. Hier ein Beispiel:

var defer = function() { 
    var result = {}; 
    result.promise = new Promise(function(resolve, reject) { 
     result.resolve = function(value) { 
      resolve(value); 
     }; 
     result.reject = function(value) { 
      reject(value); 
     }; 
    }); 
    return result; 
}; 

var deferred = defer(); 
deferred.promise.then(function(value) { 
    alert(value); 
}); 
deferred.resolve(10); 

Ich bin neugierig, gibt es irgendwelche Designfehler in dieser Lösung wie Leistungsabschwächung oder Unrichtigkeit.

Antwort

15

Sie erstellen unnötige Funktionsobjekte.

Sie können einfach tun:

var defer = function() { 
    var result = {}; 
    result.promise = new Promise(function(resolve, reject) { 
     result.resolve = resolve; 
     result.reject = reject; 
    }); 
    return result; 
}; 

Designfehler dies in erster Linie tut, einheimische Versprechungen sind nutzlos, wenn Sie Q. verwenden

+1

"Einheimische Versprechen sind nutzlos" - warum? Würde man nicht bessere Optimierungen etc. in ihnen erwarten? – Bergi

+2

Erstens ist Versprechen perf ist nutzlos auf der Client-Seite, zweitens sind native Versprechungen sehr langsam (im Gegensatz zu fast jeder anderen nativen Implementierung langsamer als Benutzer implementiert). Drittens haben ES6-Versprechungen nur eine sehr geringe Funktionalität und sind bei realen Projekten kaum einsatzbereit. – Esailija

+0

@Bergi iirc im Moment sind die Versprechen von Eingeborenen schneller als die Versprechen von Q, aber langsamer als Bluebird verspricht - das ist wirklich nicht die Sorge, wie Petka sagte. Der störendere Teil ist, dass sie schlechtere Stack-Spuren haben als Bluebird verspricht: D –

5

Siehe http://bluebirdjs.com/docs/benchmarks.html für Benchmarks. Es gibt auch einige JSPerf-Benchmarks, aber "für eine einigermaßen schnelle Versprechungen wird die Implementierungslatenz vollständig durch den verwendeten Scheduler bestimmt und ist daher für Benchmarks nicht interessant. JSPerfs, die Benchmarks versprechen, tendieren dazu, Latenzzeiten zu messen."

+2

Updates für 2015? –