modale Fenster

[Felix Riesterer]

Lieber dedlfix,

Habs mir mal angeschaut. Dazu ein paar Anmerkungen.

wunderbar! Vielen Dank!

Die Variable p wird durch einen lokalen Scope überlagert. [...] Ich würde das lokale p etwas sprechender (um)benennen, zum Beispiel node, denn es sind ja nicht nur ps zu entfernen .

Ja, das wäre sehr sinnvoll.

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.

Dieses const kenne ich noch nicht so lange wie var. Beide sind für mich nur dazu da, eine Variable nicht als Eigenschaft von window, also als globale Variable zu definieren, sondern als lokale. Dabei ist mir das var ebenso lieb, wie das const, nur dass ich mich an letzteres noch nicht gewöhnt habe. Mir ist es völlig egal, ob man den Inhalt von const später mit einem anderen Datentyp befüllen kann, oder nicht - wegen mir bräuchte es das überhaupt nicht. Aber für ein Tutorial sollte man diese Unterscheidung durchaus nutzen.

Die von querySelectorAll() zurückgegebenen NodeList ist non-live und braucht keine slice()-Kopie, um damit gefahrlos arbeiten zu können.

Deswegen tue ich es auch nicht.

Und obwohl sie kein Array ist, forEach() hat sie jedenfalls.

In wirklich allen Browsern? Zuletzt meine ich mich zu erinnern, wollte es im IE nicht so recht. Ist das jetzt nicht mehr so?

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.

Wieder so etwas neumodisches. grins Von mir aus darf es for..in oder auch for..of sein. Ich sehe jetzt nicht, wo prototypische Eigenschaften hoch kommen sollten. Aber man muss es ja nicht erst darauf anlegen.

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.

Ich empfand das immer als "unsauber", weil eine so definierte Variable nicht am Anfang meines Programms steht. Aber der Scope innerhalb einer Schleife geht ja nicht nach außen, daher würde prop tatsächlich so nur innerhalb der Schleife existieren. Also besser.

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

Du meinst ein Boolean true würde sonst auch akzeptiert? Kann das als Bezeichner einer Eigenschaft überhaupt sein?

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.

So betrachtet schon. Ich habe mir immer angewöhnt, auf das prinzipielle Vorhandensein zu prüfen. Daher die erste Bedingung. Sollte also jemand vergessen haben, dass das Objekt noch eine type-Eigenschaft benötigt, und würde die erste Bedingung fehlen, dann würde der Code mit einer Fehlermeldung in der Konsole abgebrochen. So aber wird das Objekt schlicht nicht verarbeitet und die Ausführung nicht unterbrochen. Ist ein silent fail an dieser Stelle wirklich schlechter, als eine echte Fehlermeldung in der Konsole?

Wenn man das Ganze noch ordentlich weitertreibt, dann würde man die Datenobjekte nicht von Hand als Literal notieren, sondern mittels einer Klasse bauen lassen, die dafür Sorge trägt, dass alle notwendigen Eigenschaften auch vorhanden sind - und als default-Typ eben info verwendet.

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.

Ja, wenn jemand damit umgehen kann. So bietet das Tutorial eine von vielen möglichen Ideen, die hoffentlich zu weiteren neuen und vielleicht sogar besseren Ideen führt.

Als Bonus kann man das HTML des Templates mit allen Finessen des HTML-Editors erstellen.

Der Phantasie sind eben keine Grenzen gesetzt. Man kann mit seiner Programmlogik alles Denkbare umsetzen.

Zu lösen wäre dabei die Frage, wie mit Formularelementen umgegangen werden soll.

Das darf jeder Entwickler für sich selbst entscheiden. Das Tutorial bietet wie ausdrücklich angemerkt nur eine von unendlich vielen Möglichkeiten das zu tun.

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.

OK. Ich zeige gleich ein Beispiel mit einer möglichen Vorgehensweise, um ein konkretes Ergebnis vorführen zu können.

Mal sehen, wann ich Deine Anregungen umsetzen kann. Jedenfalls noch einmal ein herzliches Danke dafür!

Liebe Grüße

Felix Riesterer