modale Fenster

[dedlfix]

Tach!

AHA! Also muss die aufgerufene Fuktion ein Promise-Objekt zurückliefern. Diesem Promise-Objekt kann man mit der then-Methode eine (Callback-)Funktion für den resolve-Fall geben, mit der catch-Methode eine für den reject-Fall.

Ist das so richtig?

Ja.

Wenn ja, dann sieht das schon ziemlich aus wie meine callBack-Sammlung, nur dass diese im Zweifel noch zwischen "cancel" und "abort" unterscheiden kann, also neben resolve und reject noch abort liefert. Ein Promise-Objekt kann das also nicht? Das fände ich dann für mein Tutorial unzureichend!

Was ist der Unterschied zwischen Cancel und Abort? Für mich ist ein Dialog erfolgreich, wenn Daten zurückzugeben sind und abgewiesen (rejected), wenn der Nutzer ihn abgebrochen hat. Meist muss man auf das Abbrechen nicht reagieren, wenn doch, kann man den Fall catch()en. Wenn es wichtig ist, unterschiedliche Abbruch-Situationen unterscheiden zu können, kann man das zwar einerseits über den error-Wert tun. Aber sind das dann andererseits immer noch Abbrüche? Ich denke, dass das dann eher unterschiedliche Rückgabewerte für den Erfolgsfall sind (resolve). Der Rückgabewert kann durchaus komplexer natur sein, also zum Beispiel auch ein Objekt mit Status-Eigenschaft und Content-Eigenschaft. Also wenn der Dialog ein Eingabefeld hat und mehrere Buttons, dann käme die Information zum ausgelösten Button in die Status-Eigenschaft und der Eingabewert ist der Content.

Ich lese gerade nach und sehe, dass man mehrere then-Methodenaufrufe machen kann, und dass Promise-Objekte wesentlich komplexer sind (Status-Werte, innere und äußere Promises, Exceptions) als meine Callback-Lösung, die ich doch als recht elegant und für den vorliegenden Fall als bequem empfinde. Wenn man jetzt noch die Buttons frei benennen könnte, wäre sie sogar luxuriös, aber das will ich in diesem Tutorial nicht auch noch behandeln.

Wir wollen das nicht zu einem Tutorial über Promises machen. Es soll lediglich gezeigt werden, wie durch die Verwendung von Promises der Verwender seinen Code besser strukturieren kann. Statt herumliegender Callback-Funktionen, die man ansonsten für nichts anderes braucht, hängen diese direkt über then/catch am Dialog-Öffner. Zugegeben, man könnte die Callbacks auch direkt als Funktion im Aufruf von myAlert() etc. notieren, aber sowas macht die Geschichte nicht lesbarer.

Schau dir mal an, wie ein Ajax-Request herkömmlich verglichen mit fetch() aussieht.

var req = new XMLHttpRequest();
req.addEventListener("load", machwas_mit_daten);
req.open(url);
req.send();

//----

fetch(url)
  .then(machwas_mit_daten);

Der (hier gekürzte) fetch()-Aufruf liest sich auch gleich flüssiger. Statt einzelner Anweisungen ist das schon fast ein Satz. Vor allem kommt die Reihenfolge besser zur Geltung: erst den Request abarbeiten, dann mit den Daten arbeiten.

Mehrere then() brauchst du für den Dialog eher nicht. Das ist kein switch-Ersatz, sondern kann man für nacheinander abzuarbeitende Tätigkeiten nutzen. Das nächste then() bekommt das Ergebnis des vorhergehenden reingereicht und nicht das Ergebnis des Promises. Der Verwender kann das nutzen, wenn er meint, in seinem Fall etwas verketten zu müssen. Du brauchst das nicht weiter zu berücksichtigen, wenn du das Promise für den Dialog erstellst.

Eine Verbesserung könnte sein: In deinem Code prüfst du, ob die Callbacks Funktionen sind, bevor du sie aufrufst. Das kann beim Promise wegfallen, weil der Callback im then() angegeben wird. Wenn der Verwender da was Komisches angibt, dann ignoriert das Promise das einfach, ohne einen Fehler zu werfen (ist so definiert). Es ist ja sowieso sein Problem, was der Verwender mit dem Ergebnis anstellt, und wenn er damit Mist macht, muss du das nicht weiter beachten noch dem vorbeugen.

dedlfix.