JPKCom DB

Playground — Tips & Tricks

Tricks for the Playground: use Live mode wisely, understand the sandbox, lose nothing, avoid common pitfalls, and combine it with other JPKCom tools.

Back to the overview: Playground · Open the tool: www.jpkc.com/tools/playground/

The manual explains every feature, the examples show the workflows. This page is about what both assume but rarely state: how to dose the Live mode, what the sandbox really means, and which pitfalls cost you time. The interface is in English, so the real button and label names appear in the original.

Use Live mode wisely

  • Turn Live off for "expensive" code. Live mode rebuilds the preview after every input (slightly delayed). With compute-heavy JS, lots of animation, or constant re-rendering, that gets choppy. Then turn the Live checkbox off and rebuild deliberately with Run (Ctrl/Cmd+Enter) — you keep control over when rendering happens.
  • Watch out for infinite loops. Your JS runs in the preview <iframe> of the same browser. A while(true) loop or an accidental runaway freezes the preview (in the extreme, the whole tab). Before testing suspect loop logic, turn Live off so a half-finished infinite loop doesn't start while you're still typing — then run it under control with Run.
  • HTML Source as a sanity check. When the preview isn't showing what you expect, switch the preview header to HTML Source. There you see the full document the Playground builds — including the order of assets, <style>, and your script at the body's end. Often a problem explains itself right there.

Understand the sandbox

The preview runs in a sandbox <iframe> without allow-same-origin. That has consequences that have nothing to do with your code and everything to do with the environment:

  • No shared storage with the host page. The preview code has no access to the Playground's cookies, LocalStorage, or DOM. That's intentional (security) — but it explains why some "normally working" browser APIs behave differently in the preview.
  • fetch to third-party APIs may fail on CORS. The preview document has an opaque origin. External scripts and styles via <script src>/<link> do load (classic scripts need no CORS), but a fetch() against an API that doesn't send open CORS headers will fail. That's not a Playground bug — it's browser security.
  • prompt/alert/popups work. The sandbox deliberately allows allow-modals and allow-popups — the demo example uses prompt(), and that works.
  • The "new tab" is the exception. Open preview in new tab opens your document as a normal page without a sandbox. That's exactly when things blocked in the embedded <iframe> run — handy for full-fledged testing, but only run code there that you trust.

Persistence: lose nothing

  • Auto-save is browser- and device-bound. Your state lives in this browser's LocalStorage. A different machine, a different browser, private/incognito mode, or cleared browser data means the state isn't there — or is gone. Don't rely on auto-save alone for anything important.
  • For permanence: Export HTML. Whatever you want to keep, export as a standalone .html file — it then lives outside the browser and can be brought back with Import HTML (see Example 6).
  • Snippets are limited and local. A maximum of eight named snippets, also only in LocalStorage. An identical name overwrites without further prompt — so give unique names if you want to keep variants side by side.
  • Reset deletes no snippets. The reset button only clears the current working state and loads the demo example; saved snippets stay. Conversely: an accidental reset is no disaster, as long as you saved anything important as a snippet or file first.

Common pitfalls

  • The HTML panel is the body only. Don't write a <!DOCTYPE>, <html>, or <head> here — the Playground adds the scaffold. What you need (meta tags, your own <link>/<script src>) still works; it goes into the generated document.
  • Inline handlers need global functions. Your JS runs at the end of the <body>. A function myFn() {} declaration is global and reachable for onclick="myFn()" from the HTML. Define the same logic as const myFn = () => … and, depending on context, it isn't global — the inline handler may not find it. So use function declarations for inline handlers (or bind events in the JS via addEventListener).
  • Bootstrap components need Bootstrap JS. Bootstrap CSS alone gives you layout and looks, but modals, dropdowns, or tooltips stay dead. Also enable Bootstrap JS (includes Popper) in the Assets dropdown. Dark Mode, in turn, is only selectable when Bootstrap CSS is active.
  • Closing tags in your code are safe. If you write a string with </script> in your JS or a </style> in your CSS, the Playground escapes it when building the preview — so your code doesn't tear open the generated document. On export this escaping is kept in the interest of a runnable document and is reversed again on import.
  • The SCSS compiler loads only the first time. The very first SCSS run briefly shows "Loading SCSS compiler…" because the library is lazy-loaded. After that it's there. An SCSS syntax error doesn't break anything but lands as an error message (with a line number) and as a CSS comment in the preview.

Combine with other JPKCom tools

The Playground is for trying things out — for everything around it there are more specialized tools:

  • Compiler — when a snippet turns into production code: compile SCSS to CSS for good and minify or beautify HTML/JS/CSS. Useful once you want to ship the Playground state.
  • Beautify — format (and de-obfuscate) someone else's minified or tangled code first, before you drop it into the Playground to understand it.
  • Source Viewer — when you only want to read and highlight code rather than run it — for 100+ languages.

More context: the overview for the big picture, the manual for every feature, and the examples for the step-by-step workflows. You can try all of it directly in the tool.