JPKCom DB

Playground — Tipps & Tricks

Kniffe für den Playground: Live-Modus klug nutzen, die Sandbox verstehen, nichts verlieren, typische Stolperfallen und die Kombination mit anderen JPKCom-Tools.

Zurück zur Übersicht: Playground · Tool live öffnen: www.jpkc.com/tools/playground/

Das Manual erklärt jede Funktion, die Beispiele zeigen die Abläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: wie du den Live-Modus dosierst, was die Sandbox wirklich bedeutet und welche Stolperfallen dich Zeit kosten. Die Oberfläche ist auf Englisch — die echten Button- und Label-Namen stehen deshalb im Original, bei Bedarf mit deutscher Erläuterung.

Den Live-Modus klug einsetzen

  • Bei „teurem" Code Live ausschalten. Der Live-Modus baut die Vorschau nach jeder Eingabe neu (leicht verzögert). Bei rechenintensivem JS, vielen Animationen oder ständigem Neurendern wird das hakelig. Schalt dann die Live-Checkbox aus und baue gezielt mit Run (Strg/Cmd+Enter) — du behältst die Kontrolle, wann gerendert wird.
  • Vorsicht mit Endlosschleifen. Dein JS läuft im Vorschau-<iframe> desselben Browsers. Eine while(true)-Schleife oder ein unbeabsichtigter Dauerlauf friert die Vorschau ein (im Extremfall den ganzen Tab). Schalt vor dem Testen verdächtiger Schleifen-Logik Live aus, damit nicht schon beim Tippen ein halbfertiger Endlos-Code startet — und führ ihn dann kontrolliert per Run aus.
  • HTML Source als Kontrollblick. Wenn die Vorschau nicht das zeigt, was du erwartest, schalt im Vorschau-Header auf HTML Source. Dort siehst du das vollständige Dokument, das der Playground baut — inklusive der Reihenfolge von Assets, <style> und deinem Skript am Body-Ende. Oft erklärt sich ein Problem schon hier.

Die Sandbox verstehen

Die Vorschau läuft in einem sandbox-<iframe> ohne allow-same-origin. Das hat Konsequenzen, die nichts mit deinem Code zu tun haben, sondern mit der Umgebung:

  • Kein gemeinsamer Speicher mit der Hauptseite. Der Vorschau-Code hat keinen Zugriff auf Cookies, LocalStorage oder das DOM des Playgrounds. Das ist Absicht (Sicherheit) — aber erklärt, warum manche „normalerweise funktionierenden" Browser-APIs in der Vorschau anders reagieren.
  • fetch zu fremden APIs kann an CORS scheitern. Das Vorschau-Dokument hat einen undurchsichtigen (opaquen) Ursprung. Externe Skripte und Styles per <script src>/<link> laden zwar (klassische Skripte brauchen kein CORS), aber ein fetch() auf eine API, die keine offenen CORS-Header schickt, schlägt fehl. Das ist kein Playground-Bug, sondern Browser-Sicherheit.
  • prompt/alert/Popups gehen. Die Sandbox erlaubt bewusst allow-modals und allow-popups — das Demo-Beispiel nutzt prompt(), und das funktioniert.
  • Der „neue Tab" ist die Ausnahme. Open preview in new tab öffnet dein Dokument als normale Seite ohne Sandbox. Genau dann laufen Dinge, die im eingebetteten <iframe> blockiert sind — praktisch zum vollwertigen Testen, aber führ dort nur Code aus, dem du vertraust.

Persistenz: nichts verlieren

  • Auto-Save ist browser- und gerätegebunden. Dein Stand liegt im LocalStorage dieses Browsers. Anderer Rechner, anderer Browser, privater/Inkognito-Modus oder geleerte Browserdaten bedeuten: Der Stand ist dort nicht da bzw. weg. Verlass dich für nichts Wichtiges allein auf das automatische Speichern.
  • Für Dauerhaftes: Export HTML. Was du behalten willst, exportierst du als eigenständige .html-Datei — die liegt dann außerhalb des Browsers und lässt sich per Import HTML zurückholen (siehe Beispiel 6).
  • Snippets sind begrenzt und lokal. Maximal acht benannte Snippets, ebenfalls nur im LocalStorage. Ein gleicher Name überschreibt ohne weitere Nachfrage — vergib also eindeutige Namen, wenn du Varianten nebeneinander halten willst.
  • Reset löscht keine Snippets. Der Reset-Button räumt nur den aktuellen Arbeitsstand auf und lädt das Demo-Beispiel; gespeicherte Snippets bleiben. Umgekehrt heißt das: Ein versehentlicher Reset ist kein Drama, solange du Wichtiges vorher als Snippet oder Datei gesichert hast.

Typische Stolperfallen

  • Das HTML-Panel ist nur der Body. Schreib hier keinen <!DOCTYPE>, kein <html> und kein <head> — das Gerüst setzt der Playground. Was du brauchst (Meta-Tags, eigene <link>/<script src>), kannst du trotzdem einsetzen; es landet im generierten Dokument.
  • Inline-Handler brauchen globale Funktionen. Dein JS läuft am Ende des <body>. Eine function meineFn() {}-Deklaration ist global und für onclick="meineFn()" aus dem HTML erreichbar. Definierst du dieselbe Logik dagegen als const meineFn = () => …, ist sie je nach Kontext nicht global — der Inline-Handler findet sie dann womöglich nicht. Für Inline-Handler also Funktionsdeklarationen verwenden (oder Events im JS per addEventListener binden).
  • Bootstrap-Komponenten brauchen Bootstrap JS. Reines Bootstrap CSS macht Layout und Optik, aber Modals, Dropdowns oder Tooltips bleiben tot. Aktiviere im Assets-Dropdown zusätzlich Bootstrap JS (enthält Popper). Dark Mode wiederum lässt sich nur einschalten, wenn Bootstrap CSS aktiv ist.
  • Schließende Tags im Code sind sicher. Schreibst du im JS einen String mit </script> oder im CSS ein </style>, maskiert der Playground das beim Bauen der Vorschau — dein Code bricht das generierte Dokument also nicht auf. Beim Export bleibt diese Maskierung im Sinne eines lauffähigen Dokuments erhalten und wird beim Import wieder zurückgedreht.
  • SCSS-Compiler lädt erst beim ersten Mal. Der allererste SCSS-Lauf zeigt kurz „Loading SCSS compiler…", weil die Bibliothek nachgeladen wird. Danach ist sie da. Ein SCSS-Syntaxfehler bricht nichts ab, sondern landet als Fehlermeldung (mit Zeilennummer) und als CSS-Kommentar in der Vorschau.

Mit anderen JPKCom-Tools kombinieren

Der Playground ist zum Ausprobieren da — für das Drumherum gibt es spezialisiertere Tools:

  • Compiler — wenn aus dem Schnipsel Produktionscode wird: SCSS endgültig zu CSS kompilieren und HTML/JS/CSS minifizieren oder beautifyen. Sinnvoll, sobald du den Playground-Stand ausliefern willst.
  • Beautify — fremden, minifizierten oder verschachtelten Code erst sauber formatieren (und deobfuskieren), bevor du ihn zum Verstehen in den Playground kippst.
  • Source Viewer — wenn du Code nur lesen und hervorheben willst, statt ihn auszuführen — für über 100 Sprachen.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jede Funktion und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.