# 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.

Source: https://www.jpkc.com/db/tools/playground/tips/

Zurück zur Übersicht: [Playground](https://www.jpkc.com/db/tools/playground/) · Tool live öffnen: [www.jpkc.com/tools/playground/](https://www.jpkc.com/tools/playground/)

Das [Manual](https://www.jpkc.com/db/tools/playground/manual/) erklärt jede Funktion, die [Beispiele](https://www.jpkc.com/db/tools/playground/examples/) 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](https://www.jpkc.com/db/tools/playground/examples/#beispiel-6-stand-sichern-und-als-datei-weitergeben)).
- **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](https://www.jpkc.com/db/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](https://www.jpkc.com/db/tools/beautify/)** — fremden, minifizierten oder verschachtelten Code erst sauber formatieren (und deobfuskieren), bevor du ihn zum Verstehen in den Playground kippst.
- **[Source Viewer](https://www.jpkc.com/db/tools/source/)** — wenn du Code nur lesen und hervorheben willst, statt ihn auszuführen — für über 100 Sprachen.

---

Noch mehr Kontext: die [Übersicht](https://www.jpkc.com/db/tools/playground/) zum großen Bild, das [Manual](https://www.jpkc.com/db/tools/playground/manual/) für jede Funktion und die [Beispiele](https://www.jpkc.com/db/tools/playground/examples/) für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/playground/).