name - window title javascript




Was ist das explizite Versprechen Bau Antipattern und wie vermeide ich es? (2)

Was stimmt damit nicht?

Aber das Muster funktioniert!

Du Glückspilz. Leider ist es wahrscheinlich nicht, da Sie wahrscheinlich Randfall vergessen haben. In mehr als der Hälfte der Fälle, die ich gesehen habe, hat der Autor vergessen, sich um den Fehlerhandler zu kümmern:

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

Wenn das andere Versprechen abgelehnt wird, geschieht dies unbemerkt, anstatt zu dem neuen Versprechen weitergeleitet zu werden (wo es gehandhabt werden würde) - und das neue Versprechen bleibt für immer ausstehend, was Undichte verursachen kann.

Dasselbe passiert, wenn Ihr Callback-Code einen Fehler verursacht - zB wenn das result keine property und eine Exception ausgelöst wird. Das würde unbehandelt bleiben und das neue Versprechen ungelöst lassen.

Im Gegensatz dazu .then() Verwendung von .then() automatisch um diese beiden Szenarien und verwirft das neue Versprechen, wenn ein Fehler auftritt:

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

Das verzögerte Antipattern ist nicht nur umständlich, sondern auch fehleranfällig . Die Verwendung von .then() für die Verkettung ist viel sicherer.

Aber ich habe alles erledigt!

"Ja wirklich?" Gut. Dies wird jedoch ziemlich detailliert und umfangreich sein, besonders wenn Sie eine Versprechens-Bibliothek verwenden, die andere Funktionen wie Annullierung oder Nachrichtenübermittlung unterstützt. Oder vielleicht wird es in der Zukunft, oder Sie wollen Ihre Bibliothek gegen eine bessere austauschen? Sie werden Ihren Code dafür nicht umschreiben wollen.

Die Methoden der Bibliotheken unterstützen nicht nur nativ alle Funktionen, sondern auch bestimmte Optimierungen. Wenn Sie sie verwenden, wird Ihr Code wahrscheinlich schneller oder zumindest durch zukünftige Versionen der Bibliothek optimiert.

Wie vermeide ich es?

Wann immer Sie feststellen, dass Sie ein Promise oder Deferred und bereits bestehende Versprechen manuell erstellen, überprüfen Sie zuerst die API der Bibliothek . Das Deferred-Antipattern wird oft von Menschen angewendet, die Versprechungen [nur] als Beobachtermuster sehen - aber Versprechen sind mehr als Rückrufe : Sie sollen zusammensetzbar sein. Jede anständige Bibliothek hat viele einfach zu bedienende Funktionen für die Zusammenstellung von Versprechen in jeder denkbaren Weise, kümmert sich um all die Low-Level-Sachen, mit denen Sie nicht umgehen wollen.

Wenn Sie die Notwendigkeit gefunden haben, einige Versprechen auf eine neue Art und Weise zu verfassen, die nicht von einer vorhandenen Hilfsfunktion unterstützt wird, sollten Sie Ihre eigene Funktion mit unvermeidbaren Zurückgestelltem als letzte Option schreiben. Ziehen Sie in Erwägung, zu einer funktionsreicheren Bibliothek zu wechseln und / oder einen Fehler in Ihre aktuelle Bibliothek einzutragen. Ihr Betreuer sollte in der Lage sein, die Zusammensetzung aus vorhandenen Funktionen abzuleiten, eine neue Hilfsfunktion für Sie zu implementieren und / oder die Kantenfälle zu identifizieren, die behandelt werden müssen.

Ich habe Code geschrieben, der etwas wie folgt ausführt:

Den Promise Konstruktor verwenden:

function getStuffDone(param) {
    return new Promise(function(resolve, reject) {
        myPromiseFn(param+1)
            .then(function(val) { resolve(val); }) // or .then(resolve)
            .catch(function(err) { reject(err); }); // or .catch(reject)
    });
} 

Verwenden von Q oder zurückgestellt:

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

Jemand hat mir gesagt, dass dies der " latente Antipattern " oder der " Promise Constructor Antipattern " genannt wird, was ist an diesem Code schlecht und warum nennt man das antipattern ?


Das zurückgesetzte Antipattern (jetzt Explizit-Konstruktion Anti-Pattern), geprägt von Esailija ist ein verbreiteter Anti-Pattern- Esailija der neue Versprechen macht, die ich selbst gemacht habe, als ich erstmals Versprechungen machte. Das Problem mit dem obigen Code ist, dass die Tatsache nicht genutzt wird, dass die Kette der Versprechen.

Versprechen können mit .then und Sie können Versprechungen direkt zurückgeben. Ihr Code in getStuffDone kann wie getStuffDone umgeschrieben werden:

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

Bei Versprechen geht es darum, asynchronen Code lesbarer zu machen und sich wie synchroner Code zu verhalten, ohne diese Tatsache zu verbergen. Versprechen stellen eine Abstraktion über einen Wert einer einmaligen Operation dar, sie abstrahieren den Begriff einer Aussage oder eines Ausdrucks in einer Programmiersprache.

Sie sollten verzögerte Objekte nur verwenden, wenn Sie eine API in Versprechungen konvertieren und dies nicht automatisch tun können, oder wenn Sie Aggregationsfunktionen schreiben, die auf diese Weise einfacher ausgedrückt werden können.

Zitieren Estagija:

Dies ist das häufigste Anti-Pattern. Es ist leicht, in das zu fallen, wenn Sie Versprechungen nicht wirklich verstehen und sie als verherrlichte Ereignisemitter oder Rückruf-Dienstprogramm betrachten. Lassen Sie uns kurz zusammenfassen: Bei den Versprechungen geht es darum, dass der asynchrone Code die meisten der verlorenen Eigenschaften des synchronen Codes, wie etwa die flache Einrückung und einen Ausnahmekanal, beibehält.





es6-promise