Umkehrung der Kontrolle in JavaScript-Rückrufen: Warum Versprechen die Antwort sind

Eine Callback-Funktion ist eine Funktion, die als Argument an eine andere Funktion übergeben wird und dann innerhalb der äußeren Funktion aufgerufen wird, um eine Art Routine oder Aktion auszuführen. Es gibt zwei Möglichkeiten, den Rückruf aufzurufen: synchron und asynchron. Es ist das grundlegendste asynchrone Muster in Javascript.

Zum Beispiel:

A und B geschehen jetzt unter der direkten Kontrolle des Haupt-JS-Programms. Aber C wird auf einen späteren Zeitpunkt verschoben und steht unter der Kontrolle einer anderen Partei, in diesem Fall der Funktion ajax(..). Im Grunde verursacht diese Art der Übergabe der Kontrolle nicht regelmäßig viele Probleme für Programme.

Allerdings reicht die Seltenheit nicht aus, um das Problem oder Problem zu ignorieren. Tatsächlich ist es eines der Hauptprobleme des Callback-gesteuerten Designs. Es dreht sich um die Idee, dass manchmal Ajax(..) oder die „Partei“, an die Sie Ihre Callback-Fortsetzung übergeben, keine Funktion ist, die Sie geschrieben haben oder die Sie direkt steuern. Oft handelt es sich um ein Dienstprogramm, das von einem Drittanbieter bereitgestellt wird.

Wir nennen dies „Kontrollumkehr“, wenn Sie an Ihrem Programm teilnehmen und die Kontrolle über dessen Ausführung einem anderen Dritten übertragen. Zwischen Ihrem Code und dem Drittanbieter-Dienstprogramm besteht ein unausgesprochener „Vertrag“ – eine Reihe von Dingen, von denen Sie erwarten, dass sie eingehalten werden.

Was ist das Problem mit „Inversion of Control“?

Es gibt ein Beispiel zum besseren Verständnis dieses Problems.

Angenommen, Sie erstellen eine Reisebuchungs-Website für Ihr Unternehmen. Sie haben eine Schaltfläche „Jetzt buchen“ hinzugefügt, die die Funktion createBooking() einer Drittanbieterbibliothek verwendet. Diese Funktion verarbeitet die Buchung und ruft dann Ihren Rückruf auf, um eine Bestätigungs-E-Mail an den Kunden zu senden.

Dieser Code könnte wie folgt aussehen:

Im Test hat alles perfekt funktioniert. Die Leute beginnen, Reisepakete auf Ihrer Website zu buchen, und alle sind mit Ihrer Arbeit zufrieden. Plötzlich, eines Tages, erhalten Sie einen Anruf von Ihrem Chef wegen eines wichtigen Problems. Ein Kunde hat ein Paket gebucht und für eine Buchung vier identische Bestätigungs-E-Mails erhalten.

Sie beginnen mit der Fehlerbehebung des Problems. Sie überprüfen den Teil des Codes, der die Bestätigungs-E-Mail sendet, und alles scheint korrekt zu sein. Anschließend untersuchen Sie weiter und stellen fest, dass das Dienstprogramm createBooking() aus der Drittanbieterbibliothek Ihre Rückruffunktion viermal aufgerufen hat, was dazu führte, dass vier Bestätigungs-E-Mails gesendet wurden.

Sie wenden sich an das Support-Team der Drittbibliothek und schildern die Situation. Sie teilen Ihnen mit, dass dieses Problem noch nie aufgetreten ist, werden es jedoch priorisieren und sich bei Ihnen melden. Nach einem Tag rufen sie Sie mit ihren Erkenntnissen zurück. Sie entdeckten, dass ein experimenteller Code, der nicht live gehen sollte, dazu geführt hatte, dass die Funktion createBooking() den Rückruf mehrmals aufrief.

Das Problem lag auf ihrer Seite und sie versicherten Ihnen, dass es behoben wurde. Sie entschuldigten sich für den Ärger und bestätigten, dass das Problem nicht noch einmal auftreten würde.

Um solche unerwünschten Probleme nach einiger Suche nach einer Lösung zu verhindern, implementieren Sie eine einfache if-Anweisung wie die folgende, mit der das Team offenbar zufrieden ist:

Aber dann fragt einer der QA-Ingenieure: „Was passiert, wenn sie den Rückruf nie anrufen?“ Hoppla. Darüber hatte keiner von euch nachgedacht!

Sie fangen an, über alle möglichen Dinge nachzudenken, die schief gehen könnten, wenn sie Sie zurückrufen. Hier ist eine Liste einiger Probleme:

• Rückruf zu früh aufrufen

• Rufen Sie den Rückruf zu spät (oder nie) an

• Rufen Sie den Rückruf zu selten oder zu oft an (wie das Problem im obigen Beispiel)

• Verschlucken Sie alle Fehler/Ausnahmen, die auftreten können

• ...

Sie werden wahrscheinlich feststellen, dass Sie in Ihrem Code viele Lösungen für verschiedene Situationen implementieren müssen, was den Code schrecklich und schmutzig macht, da er in jedem einzelnen an ein Dienstprogramm übergebenen Rückruf erforderlich ist.

Versprechen

Was wäre, wenn wir diese Umkehrung der Kontrolle rückgängig machen könnten? Was wäre, wenn wir, anstatt die Fortsetzung unseres Programms an eine andere Partei weiterzugeben, erwarten könnten, dass es uns die Fähigkeit zurückgibt, zu wissen, wann seine Aufgabe abgeschlossen ist, und unser Code dann entscheiden könnte, was als nächstes zu tun ist?

Promises bieten eine leistungsstarke Möglichkeit, asynchrone Vorgänge in JavaScript zu handhaben und Probleme wie Callback-Hölle und Umkehrung der Kontrolle zu lösen. Im Gegensatz zu Rückrufen können Sie mit Promises asynchrone Aufgaben verwalten, ohne die Kontrolle über Ihren Code aufzugeben.

Erwägen Sie, einen Cheeseburger in einem Fastfood-Restaurant zu bestellen. Sie erhalten eine Quittung, eine Zusage für Ihren zukünftigen Cheeseburger. Während Sie warten, können Sie andere Dinge erledigen und wissen, dass Sie Ihre Bestellung irgendwann erhalten. Ebenso stellt ein Promise in JavaScript einen zukünftigen Wert dar, der einen reibungslosen Ablauf Ihres Codes ermöglicht.

Versprechen gehen auch mit Misserfolgen elegant um, genauso wie Sie möglicherweise informiert werden, wenn das Restaurant keine Cheeseburger mehr hat. Diese Struktur macht Ihren Code lesbarer und wartbarer.

Ich werde hier nicht näher auf Promises eingehen, aber durch deren Verwendung können Sie saubereren, zuverlässigeren asynchronen Code schreiben und so die Gesamtqualität Ihrer JavaScript-Anwendungen verbessern.

Beispielsweise können wir bei der zuvor beschriebenen Reisebuchungswebsite, wenn das Drittanbieter-Dienstprogramm eine Zusage zurückgibt, wie folgt vorgehen:

Sobald ein Versprechen gelöst (erfolgreich erfüllt) ist, bleibt es für immer so – es wird an diesem Punkt zu einem unveränderlichen Wert und kann dann so oft wie nötig eingehalten werden. Das bedeutet, dass bei einem aufgelösten Versprechen auf den aufgelösten Wert zugegriffen werden oder dieser mehrmals in Ihrem Code verwendet werden kann, ohne dass sich dies auf seinen Status auswirkt. Dadurch können Sie das Ergebnis des asynchronen Vorgangs in verschiedenen Teilen Ihrer Anwendung verarbeiten, ohne sich Sorgen machen zu müssen, dass sich das Versprechen ändert oder neu bewertet wird.

Versprechen sind eine Lösung für die Umkehrung von Kontrollproblemen, die in Nur-Callback-Code auftreten. Rückrufe stellen eine Umkehrung der Kontrolle dar. Das Umkehren des Rückrufmusters ist also tatsächlich eine Umkehrung der Umkehrung oder eine Umkehrung der Kontrolle. Wiederherstellung der Kontrolle über den aufrufenden Code dort, wo wir sie ursprünglich haben wollten.

Referenzen

• Sie kennen JS nicht: Async & Performance von Kyle Simpson

• developer.mozilla.org

Das obige ist der detaillierte Inhalt vonUmkehrung der Kontrolle in JavaScript-Rückrufen: Warum Versprechen die Antwort sind. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!