Developer Tools Overview

StringTune ships a family of developer-only modules that render overlays and controls on top of your page while you build it. They are separate from the runtime modules that power the final experience. Right now these dev-tools are in early access: importing them is not enough on its own, because they also require a valid accessDevtoolToken.

This section focuses on using and configuring the built-in dev-tools that ship with the package. It is not a guide to building your own dev-tool module from scratch.

Get a free early-access token here: https://access.fiddle.digital/.

The dev-tools family answers questions your runtime code cannot answer out loud:

• Where do my enter and exit triggers actually fire?
• Is this element really aligned to the 12-column grid?
• What does this animation look like halfway through its progress?
• Is the card I'm aligning sitting exactly on a ruler?

When a dev-tool is enabled, it joins a shared floating dock in the bottom-left of the viewport. Each tool installs a button, a hotkey, and its own overlay. None of it is styled by your site, and none of it ships when you do not register it.

How dev-tools differ from runtime modules

The tool catalog

Foundation

• Dock and shared infrastructure — how all dev-tools plug into the same floating dock, how hotkeys and saved preferences work, and how to collapse the dock.

Overlays

• StringDevInview — draws the enter/exit trigger geometry for every object, and lets you flip an element's in-view state by hand.
• StringDevLayout — per-element grid HUD (columns, rows, center, rule of thirds, golden rectangle, dot grid) with draggable settings panels.
• StringDevProgress — a scrubber for any progress-driven object: slide, type an exact value, or play the timeline forward and backward.
• StringDevRulers — draggable global guide lines with snap to element edges and layout grids.

Hotkey reference

All hotkeys are intercepted globally and are automatically ignored while you are typing in an input, textarea, select, or editable region.

Early-access token setup

Dev-tools are currently not part of the unrestricted runtime surface. The package validates accessDevtoolToken before enabling any StringDev* module.

Minimal setup:

import StringTune, {
  StringDevInview,
} from '@fiddle-digital/string-tune';

const stringTune = StringTune.getInstance();

stringTune.setupSettings({
  accessDevtoolToken: import.meta.env.VITE_STRING_TUNE_DEVTOOLS_TOKEN,
});

if (import.meta.env.DEV) {
  stringTune.use(StringDevInview);
}

stringTune.start(60);

If the token is missing or invalid, the dev-tool modules are not enabled.

Do not hardcode a real token into public docs or client-side source. If a browser can use it, a user can extract it too.

Registering dev-tools

import StringTune, {
  StringDevInview,
  StringDevLayout,
  StringDevProgress,
  StringDevRulers,
} from '@fiddle-digital/string-tune';

const stringTune = StringTune.getInstance();

if (import.meta.env.DEV) {
  stringTune.use(StringDevInview);
  stringTune.use(StringDevLayout);
  stringTune.use(StringDevProgress);
  stringTune.use(StringDevRulers);
}

stringTune.start(60);

This assumes accessDevtoolToken is already configured. Each tool decides on its own when to attach to a given element:

• Global tools (Inview, Rulers) watch the whole document.
• Element tools (Layout, Progress) only connect when an element declares the matching activation attribute.

Keeping dev-tools out of production

There is no global kill switch. The contract is simple: do not import or register dev-tools in a production build. Because they are separate named exports, tree-shaking removes them when your build never references them.

Typical patterns:

// Nuxt / Vite
if (import.meta.env.DEV) {
  const { StringDevInview } = await import('@fiddle-digital/string-tune');
  stringTune.use(StringDevInview);
}

// Next.js
if (process.env.NODE_ENV !== 'production') {
  const mod = await import('@fiddle-digital/string-tune');
  stringTune.use(mod.StringDevInview);
}

The dock itself only appears after at least one dev-tool is enabled; an empty dock is never rendered.

Recommended loading patterns

If your team uses dev-tools regularly, it helps to keep registration predictable instead of sprinkling use(...) calls across unrelated files.

Good patterns:

• Set accessDevtoolToken once in the same app-level bootstrap.
• Register all dev-tools in one app-level dev bootstrap.
• Load them only in development mode.
• Keep runtime modules and dev-tools separate, so production behavior never depends on a debugging overlay being present.

Example:

import StringTune, {
  StringProgress,
  StringDevInview,
  StringDevLayout,
  StringDevProgress,
  StringDevRulers,
} from '@fiddle-digital/string-tune';

const stringTune = StringTune.getInstance();

stringTune.use(StringProgress);

if (import.meta.env.DEV) {
  stringTune.use(StringDevInview);
  stringTune.use(StringDevLayout);
  stringTune.use(StringDevProgress);
  stringTune.use(StringDevRulers);
}

stringTune.start(60);

Recommended workflows

The built-in dev-tools become more useful when you treat them as a set instead of isolated overlays:

• Use Inview first to confirm where a timeline starts and ends.
• Add Progress when you need to scrub a single progress-driven element without scrolling.
• Use Layout when an element itself needs a composition guide.
• Use Rulers when you need free-floating alignment checks across distant parts of the page.

Typical flow for a scroll animation:

1. Register StringProgress and StringDevInview.
2. Confirm the enter/exit geometry on the target element.
3. Add StringDevProgress to scrub through the same element at exact values.
4. If the composition still feels off, layer StringDevLayout or StringDevRulers on top to check alignment.

Persisted preferences

Every dev-tool that stores user preferences remembers them in your browser. The dock also saves its own collapsed/expanded state and which tools are active.

Clearing browser storage for the site resets everything to defaults — guide lines, saved grid configurations, marker positions, dock collapse state, and per-tool active toggles.

Where to go next

• Start with the Dock guide if you want to understand the shared surface before diving into individual tools.
• Jump straight to a tool page if you know which overlay you need.