JavaScript JS bei Laden der Seite ausführen?

[Dsimon24]

Hallo zusammen,

folgende Frage gehört wahrscheinlich zu den Basics,
aber dennoch finde ich darauf leider keine Lösung.

Mit folgendem Link öffnet sich eine entsprechende Chatbox:

<a href="#" data-api="smartsupp" data-operation="open">Open chat ...</a>

Dies möchte ich aber nun ohne Klick auf einem
Link, sondern direkt bei dem Betreten der Seite
realisieren - wie kann ich da am besten vor-
gehen?

VG, David

 

[psYcho-edgE]

über document.onload bzw. window.onload (je nachdem zu welchem Zeitpunkt du das ausführen willst) die JS-Funktion ausführen, die hinter deinem Link dafür sorgt dass die Chatbox auftaucht

wäre zumindest meine erste Wahl

 

[areiland]

Dafür gibts das "Onload" Event, von dem beim Laden der Seite die dort hinterlegten Ereignisse ausgeführt werden.

 

[Dsimon24]

Die Möglichkeit habe ich auch schon mal angedacht, aber wie
realisiere ich das Öffnen mit den vorhandenen Parametern
aus dem Link in einer Funktion?

 

[pcBauer]

Wenn du JQuery zur Verfügung hast , kannst du $('document').ready(function(){}); verwenden, falls nicht, sind die von den Anderen genannten Optionen die gängigen Varianten.

Laut StackOverflow soll es auch reichen eine selbstausführende Funktion (nicht abschrecken lassen von den vielen Klammern) ganz unten im Body zu deklarieren, so sollte das in etwa funktionieren:

<a id="chatLink" href="#" data-api="smartsupp" data-operation="open">Open chat ...</a>

<script>
  (function() {
    document.getElementById("chatLink").click();
  })();
</script>

 

[Dsimon24]

Vielen Dank euch,

mit dem Beispiel von pcBauer habe ich jetzt die folgende
Funktion erstellen können:

$( document ).ready(function() { setTimeout(function(){document.getElementById("chatLink").click();}, 1200); });

Nun wird die Box nach dem Laden der Seite geöffnet.

 

[psYcho-edgE]

Laut StackOverflow soll es auch reichen eine selbstausführende Funktion (nicht abschrecken lassen von den vielen Klammern) ganz unten im Body zu deklarieren, so sollte das in etwa funktionieren:

Was im Endeffekt nichts wirklich anderes ist als document.onload nur relativ "dirty". Das Skript wird halt grob gesagt dann ausgeführt, wenn der DOM-Parser an der Stelle vorbeikommt, das heißt kurz vor Schluss. Da könnten aber einige wichtige Teile der Seite noch nicht bereit sein wenn man Pech hat.

 

[captmcneil]

Es ist ohnehin eine gute Idee, Skripte ans Ende der Seite zu packen.

• Skripte werden dort ausgeführt, wo sie definiert sind, und das HTML-Dokument existiert für das Skript auch nur bis dahin, d.h. nachfolgende Elemente sind ggfs. noch nicht da. Am Ende des body ist das document quasi ready, und man braucht das Event nicht mehr so sehr.
• Außerdem blockieren Skripte den Aufbau des Dokuments, d.h. wenn man im head mehrere hundert KB Skripte nachlädt, bleibt auf einer langsamen Mobile-Verbindung die Seite weiß, während das Dokument sich schonmal aufbaut, wenn das Laden am Ende des body erfolgt.

Soweit möglich, sollte JavaScript übrigens auch "non-intrusive" sein. Das bedeutet unter anderem, dass man sich nicht zu sehr darauf verlassen sollte, an welcher Stelle das Skript läuft. Konkret ist es z.B. besser, ein Event mit einem Selektor auf das document zu registrieren, als direkt an das Element, oder in einem document.ready-Event.

$(document).on('click', '#my-button', function() {...});

Solche Skripte fallen nicht mehr so leicht um, wenn sie zu weit oben oder unten eingebunden werden, da der Selektor immer beim Klick ausgewertet wird. Als Bonus funktioniert das Event auch für nachträgliche, dynamisch erzeugte Elemente.

 

[psYcho-edgE]

@captmcneil wenn man net alles mit Libraries á jQuery zukleistert könnte man sich das auch sparen. Es gibt auch Sachen die sollten unbedingt vor dem Aufbau des Body verfügbar sein.

Aber ja, grundsätzlich lieber unten als oben.

 

[captmcneil]

@captmcneil wenn man net alles mit Libraries á jQuery zukleistert könnte man sich das auch sparen. Es gibt auch Sachen die sollten unbedingt vor dem Aufbau des Body verfügbar sein.

Aber ja, grundsätzlich lieber unten als oben.

Ganz ehrlich, ich würde auch heute nicht freiwillig Vanilla-JS im Browser programmieren. Ich halte das Native-DOM nach wie vor für eine grausame API, es "stinkt" nach Java. So lange IE11 nicht 100% tot ist, hätte ich auch keine Lust auf die Whitespace-Textnode-Problematik. Und viele verbreitete Toolkits/Bibliotheken brauchen es entweder ohnehin, oder haben eine wesentlich kleinere jQuery-Variante.

 

[psYcho-edgE]

Wobei man sagen muss dass es deutlich besser geworden ist Vanilla zu nutzen, mal davon ab dass es für viele kleine Sachen dicke ausreicht. Aber ist glaube auch ne Frage wie man ursprünglich zu JS gekommen ist wie man zu jQuery steht. Ist wie Marmite, manche lieben es, manche hassen es

 

[captmcneil]

Wobei man sagen muss dass es deutlich besser geworden ist Vanilla zu nutzen, mal davon ab dass es für viele Sachen dicke ausreicht. Aber ist glaube auch ne Frage wie man ursprünglich zu JS gekommen ist.

Keine Frage, es hängt auch davon ab, was man machen will. In einer kontrollierten Backend-Umgebung mit festem Browser und SPA kann ich auch ganz andere ECMAScript-Standards benutzen. Auf einer Website für die Altersgruppe 40+, die auch noch das letzte IPad 2 und Leute mit NoScript und Adblocker abholen muss, sieht's anders aus.

 

[psYcho-edgE]

Wobei ja gerade NoScripter auf Vanilla angewiesen wären, oder? Hab mich in der Richtung noch gar nicht wirklich beschäftigt... Vllt per DM schlauer, wird etwas OT