modale Fenster

[dedlfix]

Tach!

[x] done

Habs mir mal angeschaut. Dazu ein paar Anmerkungen.

Die Variable p wird durch einen lokalen Scope überlagert.

        // jedes <ul> und <p> entfernen, außer <p class="button-row">
        Array.prototype.slice.call(
            dialog.querySelectorAll("ul, p:not(.button-row)")
        ).forEach(function (p) {
            p.parentNode.removeChild(p);
        });

Ich würde das lokale p etwas sprechender (um)benennen, zum Beispiel node, denn es sind ja nicht nur ps zu entfernen . Zudem muss p nicht "global" in myDialog rumliegen sondern kann als const p = ... innerhalb der For-Schleife im dortigen lokalen Scope existieren. Der Wert wird nie verändert, weswegen sie als const deklariert werden kann. Ebenso geht es der Variable element und elements, die jeweils nur innerhalb eines eines Blocks existiert. Alle anderen var können auch zu const umgeschrieben werden, weil sich ihr Inhalt nicht ändert.

Außerdem lässt sich obiger Code problemlos kürzen zu:

        dialog.querySelectorAll("ul, p:not(.button-row)")
            .forEach(function (node) {
                node.parentNode.removeChild(node);
            });

Die von querySelectorAll() zurückgegebenen NodeList ist non-live und braucht keine slice()-Kopie, um damit gefahrlos arbeiten zu können. Und obwohl sie kein Array ist, forEach() hat sie jedenfalls.

Bei beiden for (prop in data) möchte das in lieber ein of sein, damit nur direkte Eigenschaften und keine eventuell aus dem Prototyp geerbten berücksichtigt werden. Das prop ist auch wieder nur lokal verwendet und kann als for (let prop of data) notiert werden, so dass man es ebenfalsl nicht "global" in myDialog braucht.

Zudem meckert meine IDE an, man solle bei diesen Stellen den typsicheren Vergleich nehmen.

if (data[prop].type && data[prop].type == "info")

Aber das ist ziemlich egal. Ob der nun Vergleich fehlschlägt, weil irgendein x-beliebiger Wert auch nach Typumwandlung nicht gleich dem gegebenen String ist oder die Typen der Werte nicht stimmen, kommt aufs gleiche raus.

Für das nachfolgende Aufrufbeispiel gilt ebenfalls das oben gesagte sinngemäß.

Generell wäre noch anzumerken, dass die Individualität sehr enge Grenzen hat. Mit einigermaßen Aufwand werden ein paar wenige Elemente unterstützt. Eine freie Gestaltung des HTML-Inhalts ist so nicht möglich. Hier wäre eine Lösung mit <template> sowohl einfacher als auch flexibler. Als Bonus kann man das HTML des Templates mit allen Finessen des HTML-Editors erstellen. Zu lösen wäre dabei die Frage, wie mit Formularelementen umgegangen werden soll. Ich würde da grundlegend nur anbieten, dass beim OK ein übergebener Callback aufgerufen werden kann, wo der Verwender das in seinem Fall benötigte Datenauslesen tun kann. Der Callback sollte ein Objekt zurückgeben, das dann vom üblichen Dialog-Handling an den Aufrufer übergeben wird. - Man kann ja immer noch für den Komfort eine vordefinierte Callback-Funktion anbieten, die ein generisches Formulardaten-Auslesen bietet. Andererseits könnte das auch gleich ein Beispiel sein, wie dieser Callback auszusehen hat.

dedlfix.