Attaform

The Attaform DevTools panel

A first-class native tab in the Nuxt DevTools sidebar. Every form's value, errors, aggregates, and event timeline, with an editable JSON tree for the values.

Category
Module
Where
Nuxt DevTools sidebar
Install
attaform/nuxt, nothing else
Production
route injection skipped, no @nuxt/devtools-kit import

This page is code-only; the panel lives in your browser's Nuxt DevTools overlay, not inside the docs site. Open any Nuxt-powered Attaform consumer in dev (Shift + Option + D opens the overlay) and pick Attaform in the sidebar to see it.

Installing

The integration is automatic; adding attaform/nuxt to your Nuxt config wires the tab:

// nuxt.config.ts: no devtools-specific config needed
export default defineNuxtConfig({
  modules: ['attaform/nuxt'],
  devtools: { enabled: true },
})

No peer dependency to add, no extension to install, no Vite plugin to configure. Open the Nuxt DevTools overlay (Shift + Option + D or click the Nuxt logo in the bottom corner) and select Attaform from the sidebar.

The tab is dev-only; production builds skip the route injection and the @nuxt/devtools-kit import entirely. Nothing ships in production.

What you see

Form list

One entry per registered form, keyed by the form's key. Click a form to inspect it.

Form value

The current form.values as an interactive JSON tree. Editable from the panel: your edit flows through setValueAtPath and drives the whole reactive pipeline (validation, persistence opt-in, history). The panel writes back into the same store the form reads from, so a value edited in DevTools is indistinguishable from one typed into an input.

Values render verbatim. The panel is dev-only, so it doesn't mask passwords / tokens / secrets; debugging a credential flow typically needs the actual value. The sensitive-name heuristic still applies elsewhere in Attaform (persistence writes, multi-tab broadcasts), it's just not applied to the dev surface. Close the panel before a screen share if a value would be sensitive on camera, the same hygiene as the browser's own DevTools console.

Schema Errors / User Errors

The error map keyed by path, split by source:

  • Schema Errors: what the validator (Zod adapter) produced. Cleared by reset() / handleSubmit success.
  • User Errors: what you wrote via setFieldErrors / addFieldErrors / the parseApiErrors server-error pipeline. Persists across revalidation and successful submits.

Splitting them tells you instantly whether validation or your application code emitted each error.

Aggregates

The reactive bundle:

  • submitting
  • submissionAttempts
  • submitError
  • activeValidations

Useful for confirming your loading-state wiring is reading the right reactive thing.

Timeline

A scrollable log of recent events. Each entry shows a timestamp, an event type, and the form key, with the form value at the moment of fire available on click.

EventFires on
form.changeEvery mutation: register inputs, setValue, array helpers, undo / redo.
submit.successA submit handler's onSubmit callback resolves.
resetreset() completes.

Capacity is capped at 200 events per session; older entries fall off the back. Hit clear to wipe the log mid-debug.

Sensitive data and the panel

The panel renders form values raw. DevTools is a dev-only surface, and redacting across every place a value surfaces (panels, logs, network tabs, breakpoints, source maps) is impractical security theater, not a real safeguard. For production-data spelunking on a sensitive surface, use a non-prod environment with synthetic data instead. The same list of names (Sensitive-name protection) still gates persistence writes and multi-tab broadcasts.

What's coming

  • Field flags (touched / focused / blurred) in the inspector: values + errors are surfaced today, UI interaction state isn't.
  • History stack visualization. Undo / redo snapshots show on the timeline via form.change entries; the stack itself isn't a separate node yet.
  • Persisted payload preview. Inspect live form state in the inspector; for the serialized payload on disk, open Application → Storage in the browser DevTools.

Caveats

  • Panel edits bypass your component bindings. Fine for poking at state during debugging; don't rely on the path mirroring production interaction exactly.
  • Multi-app setups. The Nuxt overlay panel reads from the most recent createAttaform() install; micro-frontend setups with parallel apps will only see one app's forms in the Nuxt panel. Reach for Vue DevTools integration when you need per-app inspection.
  • Screen-share hygiene. The panel renders raw values. Close it before screen-sharing, the same way you'd close the browser DevTools console.

Where to next

Edit this page on GitHub