Wenn keine Versprechen zu verwenden sind [geschlossen]

Einige Faustregeln:

1. Wenn Ihre Methode synchron sein kann (einfache Datenumwandlung), verwenden Sie in dieser Methode synchronen Code.

   Wenn die Methode jedoch synchron manchmal und asynchron manchmal sein kann (mehrere Codepfade basierend auf dem internen oder externen Status), sollte sie asynchron immer . Andernfalls können unerwartete kleine Diskrepanzen auftreten, wenn sich Ihr Code in komplexen Szenarios verhält. Daher sollten Sie die beiden Einstellungen nicht mischen.

   [Bearbeiten] Wie bereits im Kommentar erwähnt, sollten Sie, wenn Ihre Methode momentan synchron ist, aber fest davon überzeugt ist, dass sie zu einem späteren Zeitpunkt möglicherweise asynchrone Arbeiten ausführen muss, die Versprechen von Anfang an verwenden, um kostspieliges Refactoring zu vermeiden .

2. Im Allgemeinen sollte Ihre API konsistent sein. Daher empfiehlt es sich, entweder Versprechungen überall oder Callbacks überall zu verwenden. Dadurch wird es einfacher, über den Code nachzudenken.

3. Wenn Sie Ultra-High-Performance-Code schreiben und / oder wenig Speicherbedarf haben, sollten Sie keine Versprechen, sondern Callbacks verwenden oder eine Versprechens-Bibliothek mit dem Schwerpunkt auf Leistung verwenden, wie bluebird , anstelle der systemeigenen Promise-Implementierung / des allgemeinen Anwendungsfalls polyfill.

4. [edit] Wie auch immer, neue Erweiterungen der Web-Plattform, wie global fetch -Funktion, gib ein Promise zurück, und es scheint, dass in den kommenden Jahren immer mehr Browser-Builts auf Versprechungen basieren werden. Also, wenn Sie bereit sind, modernen Code zu schreiben, werden Sie Versprechen nicht entgehen.

Sie verwenden Versprechen für einmalige asynchrone Vorgänge. Initiieren Sie den Vorgang, führen Sie den Vorgang aus, benachrichtigen Sie einen Anrufer über die Beendigung oder die Ergebnisse oder den Fehler, und machen Sie es dann endgültig.

Die Situationen, in denen Sie keine Versprechen verwenden sind anders als oben beschrieben:

1. Wenn Ihre Operation oder Funktion vollständig synchron ist . Eine asynchrone API (selbst mit Versprechungen) in eine synchrone Operation zu integrieren, macht die Dinge nur komplexer als nötig.
2. Anstelle von Ereignissen , die mehrmals auftreten können. Beispielsweise würden Sie kein Versprechen für einen Button-Klick-Handler verwenden. Ein eventEmitter oder eine andere ereignisähnliche Struktur ist immer noch eine bessere Struktur für wiederkehrende Ereignisse.
3. Wenn Sie eine Rückrufsituation haben, bei der der Rückruf so ausgelegt ist, dass er mehrmals aufgerufen werden kann (z. B. Fortschrittsmeldung oder Bereitstellung eines Plug-in-Dienstes über Rückruf).
4. Wenn Sie einer API eine neue Operation hinzufügen, die bereits auf andere Weise entwickelt wurde (z. B. mit herkömmlichen Rückrufen) und API-Konsistenz gewünscht wird.
5. Wenn Sie auf ältere Umgebungen ausrichten , die Promises (wie alte Browser) nicht nativ unterstützen, versuchen Sie, die Download-Größe Ihres Codes zu optimieren, und Sie tun nur ein oder zwei asynchrone Operationen und Sie verwenden nicht so etwas wie jQuery oder Angular, die bereits eine Form von Versprechen eingebaut haben, die Sie einfach verwenden können. Wenn Sie eine erhebliche Menge an asynchronen Arbeiten ausführen, ist es wahrscheinlich sinnvoll, ein Promises-Polyfill zu verwenden. Dieser Punkt ist nur für Fälle gedacht, in denen die Größe extrem wichtig ist und sehr wenig asynchrone Arbeit stattfindet.
6. Für Situationen , bei denen die Aktion häufig nicht abgeschlossen wird oder auftritt . Versprechen sind ein Objekt mit Zustand und verbrauchen daher etwas Speicher. Es würde keinen Sinn machen, Tausende von Versprechungen zu machen, um über viele verschiedene Dinge informiert zu werden, die normalerweise nicht auftreten, weil dies Tausende von Versprechungsobjekten (normalerweise mit ihren zugehörigen Schließungen) erzeugen würde, die sich meistens nie nutzen würden. Dies ist nur ineffiziente Speichernutzung und ist wahrscheinlich besser durch eine Art Ereignisbenachrichtigung gedient. Wie ich oben sagte, funktionieren Versprechen am besten, wenn Sie eine Operation initiieren, die Operation ausführen, den Anrufer über Ergebnisse oder Fehler benachrichtigen.

Nun Versprechen haben einen Anwendungsfall: asynchrone Ergebnisse, die nur einmal kommen.

Sie verwenden Promises nicht, wenn Sie das Ergebnis synchron zurückgeben können und Sie weiterhin Callbacks für Ereignisse benötigen, da diese mehrfach auftreten können.

Sie können sich entscheiden, Promises nicht zu verwenden, wenn Sie möchten, dass Ihr Code im Browser ausgeführt wird (die möglicherweise keine Promises enthält) und die Größe WIRKLICH wichtig ist, sodass Sie es sich nicht leisten können Versprechen shims / libs.