JPKCom DB

Playground — Tipps & Tricks

Kniffe für den Playground: Live-Modus klug nutzen, die Sandbox verstehen, den PHP-Modus im Griff behalten, 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.

Den PHP-Modus im Griff behalten

  • Keine Live-Vorschau — und das ist gut so. Im PHP-Modus läuft PHP per WebAssembly auf dem Haupt-Thread. Eine Endlosschleife ließe sich nicht von außen abbrechen und würde den Tab einfrieren. Deshalb gibt es bewusst kein Auto-Run beim Tippen: Du baust immer kontrolliert per Run PHP (Strg/Cmd+Enter). Bei verdächtiger Schleifen-Logik also erst fertig schreiben, dann ausführen.
  • Fehler stehen im PHP Log, nicht in der Ausgabe. PHP ist so eingestellt, dass Warnungen, Notices und Fehler nicht die Vorschau verschmutzen, sondern im PHP Log landen (mit Zeilennummer). Bleibt die Vorschau leer oder zeigt nicht das Erwartete, ist das Log die erste Anlaufstelle — der rote Badge am Button verrät schon, ob etwas anliegt. Auch dein eigenes error_log(...) landet dort.
  • Der erste Start dauert. Beim Aktivieren werden rund 13 MB PHP-Engine geladen — einmalig und nur online. Danach liegt sie im Browser-Cache. Schaltest du PHP wieder aus, gibt der Playground den Speicher frei.
  • PHP-Export ist nicht standalone. Ein Export HTML im PHP-Modus enthält den rohen HTML+PHP-Quelltext (playground.php.html) — re-importierbar, aber im Browser allein nicht lauffähig, weil das PHP unausgeführt ist. Für ein fertig laufendes Dokument zum Weitergeben erst per Run PHP rendern und dann aus der Vorschau heraus arbeiten — oder den Modus für reines Front-End wieder ausschalten.
  • Kein Server, keine Datenbank. Der Modus führt PHP-Logik aus, aber ohne Webserver, DB oder Dateisystem deines Rechners. Ideal für Snippets, Funktionen und Sprach-Features — kein Ersatz für eine echte PHP-Umgebung.

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.