modale Fenster

[Felix Riesterer]

Lieber dedlfix,

const/let gibt es ja auch noch nicht so lange. Aber laut CanIUse kann das sogar der IE11 in Grundzügen.

sind Grundzüge ausreichend, dass ein Tutorial-Leser, der das in seinem IE ausprobiert, damit auch nicht scheitert?

Vermutlich ist const für die Laufzeitumgebung interessant, dass es da besser optimieren kann als bei veränderbaren Variablen.

Wenn ein JS-Neuling den Code mit seinem IE ausprobiert und an const/let scheitert, wem ist denn dann damit geholfen, dass ich kein var benutzt habe?

Naja, keiner der IEs hat diese Methode an der NodeList.

Also bleibe ich besser noch bei meiner Array.prototype.slice.call-Weise, damit's auch beim noob im IE funzt.

Wenn man es schafft, die Funktionen mit beschreibenden Namen zu versehen, hat man als Leser gleich noch einen Hinweis auf das, was die Funktion tun soll, ohne erst den Code verstehen zu müssen und auch ohne dass da ein Kommentar zur Erläuterung steht.

Ist das in meinen Beispielen nicht gegeben?

So betrachtet schon. Ich habe mir immer angewöhnt, auf das prinzipielle Vorhandensein zu prüfen. Daher die erste Bedingung.

Diesen Teil hatte ich gar nicht beachtet, nur den Vergleich nach dem &&. Aber jetzt wo du es sagst, fällt mir auf, dass ich doch was daran auszusetzen habe.

Also gut. Da data[prop] zwingend existiert (kann ein leerer Wert unter diesem Eigenschaftsnamen sein), kann ich gleich data[prop].type auf den Wert testen, den ich haben will (also info).

Außerdem muss ich mich in einem Punkt revidieren. for...of geht nur mit iterierbaren Dingen wie Arrays. Objekte gehören ohne Spezialbehandlung nicht dazu. Das muss also weiterhin eine for...in-Schleife bleiben, damit das über die Objekteigenschaften laufen kann.

Danke für diese erweiterte Klarstellung. Mich freut, dass ich meinen Code an dieser Stelle nun doch nicht anzupassen brauche.

Falls man die prototypische Vererbung verhindern möchte, muss man das über hasOwnProperty() prüfen und entsprechend verzweigen. Das kann man hier aber wohl weglassen.

Sehe ich auch so.

Jein, wenn es "ordentlich" sei sollte, müsste man dieses XY-Problem durch Verwendung von <template> vermeiden.

Aha... OK. Das überblicke ich jetzt gerade nicht, da ich mich noch nicht mit Templates befasst habe.

Da hast du mich wohl missverstanden. Ich meinte, dass dein Ansatz über das Konfigurationsobjekt nicht nur bei der Gestaltung des Dialoginhalts einschränkt auf das was der dieses Objekt auswertende Code bietet, auch im Editor beim Erstellen des Objekts hat man keinerlei Hilfe durch Autovervollständigung und ähnliche Hilfsmittel.

Meine Zielgruppe erwartet wohl solche Features in diesem Zusammenhang nicht. Und wenn, dann braucht sie mein Tutorial wahrscheinlich nicht mehr. Mein Ansatz geht auch nicht in die Richtung, dass die Dialoge wirklich alle Möglichkeiten ausreizen, sondern dass sie programmatisch erstellt werden können, um übliche Formulardaten erfassen zu können und so über confirm und prompt weit hinaus gehen. Wer noch mehr will, geht freilich anders vor!

Man erstellt ein Objekt mit für die IDE unbekannte Struktur. Wenn man die Eigenschaften nicht richtig tippt, gibt es zur Laufzeit kein Ergebnis. Wenn man stattdessen den Dialoginhalt direkt als HTML notieren könnte, wäre die IDE in der Lage, Syntaxprüfungen und Vervollständigung anzubieten.

Das will der Profi. Der Profi sucht aber nicht mehr unser Tutorial hier zum Lernen auf. Oder doch?

Liebe Grüße

Felix Riesterer