Frage zum Wiki-Artikel „template“ fertig geladen

[Henry]

Hallo,

das <template> Element eigent sich sehr gut für Sachen wie im Artikel bereits sehr gut beschrieben.

Ein Problem bleibt aber, welche Möglichkeiten habe ich rauszufinden wann nachgeladene Inhalte darin zur Verfügung stehen, also fertig geladen sind?

Beispiel, ich packe in einen Template-Tag diverse externe Scripts hinein, also <script src=.....> Je nach Auslieferung und Grösse kann das aber etwas dauern, nachdem ich diese durch Klonen des Template-Inhalts aktiv mache. Jetzt könnte ich wahrscheinlich (noch nicht getestet) bei jedem dieser Scripte eine Loadabfrage einbauen. Doch bevor ich mich daran versuche, erst mal nachgefragt ob keine einfachere, viell. genau dafür vorgesehene Möglichkeit bereits besteht? Also sowas wie if(template.content.complete.loaded) do this...

Gruss
Henry

[JürgenB]

Hallo Henry,

zum Warten auf das Laden eines Scriptes verwende ich folgende Techniken:

• Das Script erledigt seine Arbeit selbst, sobald es geladen ist.
• Das Script ruft nach dem Laden selbst eine Funktion mit bekanntem Namen auf.
• Das Script ruft nach dem Laden selbst eine Funktion auf, deren Name dem Script beim Einbinden mitgegeben wurde (… src="xyz.js?cb=tuwas" … )
• Über Custom-Events definiert das Script ein eigenes Load-Event.
• Das Load-Event des Script-Elements erledigt die Arbeit.

Mein momentaner Favorit sind die Custom-Events.

Gruß
Jürgen

[Der Martin]

Hallo Jürgen,

• Das Script erledigt seine Arbeit selbst, sobald es geladen ist.
• Das Script ruft nach dem Laden selbst eine Funktion mit bekanntem Namen auf.
• Das Script ruft nach dem Laden selbst eine Funktion auf, deren Name dem Script beim Einbinden mitgegeben wurde (… src="xyz.js?cb=tuwas" … )
• Über Custom-Events definiert das Script ein eigenes Load-Event.
• Das Load-Event des Script-Elements erledigt die Arbeit.

das ist ja eine beachtliche Auswahl an Möglichkeiten.

Mein momentaner Favorit sind die Custom-Events.

Ich glaube, mein Favorit wäre eher ein Callback. Ja, ich bin mit C groß geworden. 😉

Live long and pros healthy,
 Martin

[JürgenB]

Hallo Martin,

das Problem bei den Callback-Funktionen ist, dass sie global ansprechbar sein müssen, bzw. global ein Namensraum (Objekt) vorhanden sein muss. Eventhandler dürfen anonym sein oder beliebig heißen und beliebig in irgendwelchen Unterobjekten versteckt sein.

Gruß
Jürgen

[Henry]

Hallo JürgenB,

einige Möglichkeiten fallen weg, sobal kein Einfluss auf das Script selbst besteht, zb. cdn's

Die Alternative, auch mit custum-event, würde also doch darauf hinauslaufen die einzelnen Scripte auf Loadstatus zu prüfen? Wenn ja, dann mach ich wohl am besten ein Schleife und frage alle einzeln ab?

Gruss
Henry

[JürgenB]

Hallo Henry,

Custom-Events werden im Script definiert und auch gefeuert. Wenn du keinen Einfluss auf die Quellen hast, bleibt nur das Load-Event des Script-Elements.

Gruß
Jürgen

[Gunnar Bittersmann]

@@Henry

Ein Problem bleibt aber, welche Möglichkeiten habe ich rauszufinden wann nachgeladene Inhalte darin zur Verfügung stehen, also fertig geladen sind?

Promises. Beispiel (zwar nicht mit template-Element, sondern das Template steht im Script, aber darum geht’s ja hier nicht).

😷 LLAP

[JürgenB]

Hallo Gunnar,

du würdest das Script mit fetch laden?

Gruß
Jürgen

[Henry]

Hallo Gunnar,

Promises. Beispiel (zwar nicht mit template-Element, sondern das Template steht im Script, aber darum geht’s ja hier nicht).

Doch genau darum gehts natürlich auch. Wie im Artikel auch beschrieben:

Sie sind eine gute Alternative zum zeitaufwendigen Nachladen von Inhalten mit Ajax oder dem dynamischen Erzeugen mit createElement, das bei komplexeren HTML-Strukturen schnell unbequem und unübersichtlich wird. Eric Bidelman stellt in diesem Artikel die Vorgängervorgehensweisen „Offscreen DOM“ und „Overloading Script“ und ihre Nachteile vor.

Gruss
Henry

[Rolf B]

Hallo Henry,

Beispiel, ich packe in einen Template-Tag diverse externe Scripts hinein,

Es tut mir fast weh, aber ich möchte das auf self-typische Weise beantworten: Löse dieses Problem so, dass Du es gar nicht entstehen lässt.

Wirklich. Ich würde das lassen. Entweder ist das Template ein Singleton, der kein- oder einmal aktiv wird, und über eine ID gefunden werden kann. Sowas kann eigenes Script mitbringen und das Script weiß dann auch, wo auf der Seite es das Template suchen muss. Wenn das Script mit anderen Scripten auf der Seite interagieren muss, ist dies der falsche Ansatz. Ein load Event auf dieses Script-Element zu registrieren würde bedeuten, dass Du das DOM, das aus dem Template entsteht, beim Einbinden erstmal nach script-Elementen durchsuchen musst. Von diesem Ansatz würde ich abraten.

Im Normalfall ist ein Template aber mehrfach verwendbar, und wenn es dann Script lädt, lädt auch das Script mehrfach. Ohne zu wissen, wo nun das neue Stück DOM steht, das aus dem Template entstanden ist.

Templates sind aus meiner Sicht etwas, das zum Gesamtkonzept einer Seite gehört. Ich gestalte eine Seite, und ich erzeuge mit JS neue Teile im DOM. Diese hole ich aus einem Template. Wenn diese Teile zum Funktionieren Script benötigen, dann sollte dieses Script unabhängig vom Template geladen werden. Und dann ist es in der Gesamtarchitektur der Seite auch bekannt. Vorzugsweise als Modul - ECMAScript oder AMD.

Wenn das Script auf Teile des Templates aufmerksam gemacht werden muss, sollte es eine Registrierfunktion anbieten, mit der man das neue DOM-Fragment mit dem Script verknüpft. Oft ist das aber nicht nötig, über Event Bubbling kann man schon eine Menge tun.

Die Frage ist auch, ob ein Template dann der richtige Weg ist oder ob man nicht über ein custom element nachdenken sollte.

Rolf

[Henry]

Hallo Rolf,

Es tut mir fast weh, aber ich möchte das auf self-typische Weise beantworten: Löse dieses Problem so, dass Du es gar nicht entstehen lässt.

dazu kann es verschiedene Sichweisen geben. Enweder es ist gar kein Problem, sondern nur ein Weg. Oder es ist ein Problem, dann würde jede andere Art von Lösung wieder neue Problem mit sich bringen.

In diesem speziellen Fall, habe ich unzählige Methoden ausprobiert und die Experimente sowohl, die Scripte als auch das notwendige Html/CSS modular einzubauen erwies sich über <template> am effizientesten und zukünftig am meisten selbsterklärend.

Ich habe einen vollständigen Editor gebaut, mit sehr viel mehr Funktionen als W3Scools Editor und extrem wenig Code. Einziges Manko was ich dabei hatte war das Syntax-Highlighting. Doch dieses Rad neu zu erfinden, war mir dann doch zu aufwendig. Das kann Codemirror besser. Nur, für den üblichen Gebrauch reicht mir meist mein Editor, also habe ich eine Möglichkeit geucht beide miteinander zu verbinden. Also mein normaler Editor, ohne externe Sachen, schnell, unkompliziert und vor allem extrem stabil, auch absolut offline zu nutzen, aber auf Knopfdruck den Codemirror darin einschalten, ja sogar switchen kann.

Daher, bin ich mit <template> absolut zufrieden, stellte sich nur die Frage(kein echtes Problem), wie ich den Loadstatus am besten abfrage.

Wirklich. Ich würde das lassen. Entweder ist das Template ein Singleton, der kein- oder einmal aktiv wird, und über eine ID gefunden werden kann. Sowas kann eigenes Script mitbringen und das Script weiß dann auch, wo auf der Seite es das Template suchen muss. Wenn das Script mit anderen Scripten auf der Seite interagieren muss, ist dies der falsche Ansatz. Ein load Event auf dieses Script-Element zu registrieren würde bedeuten, dass Du das DOM, das aus dem Template entsteht, beim Einbinden erstmal nach script-Elementen durchsuchen musst. Von diesem Ansatz würde ich abraten.

Das wurde alles bereits bedacht und funktioniert problemlos, und ja mit ID's.

Gruss
Henry

[Rolf B]

Hallo Henry,

ok, du aktivierst also via Template eine 3rd party Komponente. Du hast keinen Einfluss darauf, was Codemirror tut, du kannst nur zuschauen.

Es dürfte auch nichts helfen, wenn Du im Template ein <script> Element ans Ende schaltest, das das Signal schickt. script-Elemente die mit dem initialen HTML geladen werden, halten die HTML Verarbeitung auf, bis sie geladen und ausgeführt sind. Aber wenn sie nachträglich ins DOM kommen, laufen sie asynchron.

Da das load-Event nicht blubbert, bleibt Dir dann nichts anders übrig als mit getElementsByTagname die Script-Elemente im Template zu suchen und einen load-Handler darauf zu registrieren.

Du kannst das kapseln, indem Du dieses Lauschen auf load in ein Inlinescript des Templates legst. Und dann deinen eigenen Signalmechanismus bedienst, z.B. ein custom event feuerst, das blubbert. Das ist aber alles Architektur um der Architektur willen, am einfachsten machst Du das in dem Code, der das Template einbindet.

Es sei denn, die Scripte im Codemirror haben bereits einen Signalmechanismus eingebaut, den Du nutzen kannst.

Rolf