Vue 2.7 + Vue 3 · Keep your UI library

One lifecycle for every admin form.

Keep Element, Naive UI, or Ant Design Vue. vformjs standardizes create, edit, detail, validation, linkage, arrays, and server errors without replacing your components.

Build the first form Try the live state

Start with @vformjs/element-plus. Drop to useForm only when you need a custom host.

profile-form.tsuseElForm

import { useElForm, r } from '@vformjs/element-plus'

const form = useElForm({
  defaults: { name: '', email: '' },
  rules: {
    name: [r.required(), r.min(2)],
    email: [r.required(), r.email()],
  },
  onSubmit: values => api.save(values),
})

form.load('edit', record) // one record, a new baseline
const { ok } = await form.submit()

Vue runtimes: 2.7 + 3
verified UI paths: 4
behavior tests: 73
core gzip: 9.54 kB

The gap between UI and business state

Your Form component validates fields. The rest still repeats.

Admin projects keep rewriting mode switches, reset baselines, submit guards, conditional rules, list keys, and API error handling. vformjs keeps the host Form in charge of visual validation and gives the repeated lifecycle one typed API.

Repeated in each screen

dialog mode branches
reset timing and stale errors
array row keys
submit loading flags
conditional rule cleanup

Owned by the form instance

load('create' | 'edit' | 'detail')
dirty + changedPaths
list('contacts')
submit() + submitting
when + whenRules

A thin orchestration layer

The host renders. vformjs keeps the lifecycle coherent.

Each API exists to remove a repeated production concern. The library does not ship replacement inputs or a second design system.

Three modes, one owner

Create, edit, and detail share one form instance inside the dialog or page.

load('edit', detail) rebases reset and dirty state.

Host-native validation

Element, Naive UI, and Antd keep their own rules, red text, and focus behavior.

Adapters bridge validate, clear, and scroll.

Typed server errors

API field errors stay reactive and clear when their field changes.

setErrors() → errors → scrollToFirstError().

Linkage without a renderer

Keep native templates while centralizing conditional state and dependent options.

when, whenRules, and linkage remain plain TypeScript.

Stable dynamic rows

Append, move, replace, and remove nested rows without using array indexes as keys.

list('items') exposes stable fields.

Schema when you need it

Use Zod for schema-only validation and parsed submit output.

The UI adapter remains optional for headless validation.

The short path

Defaults, one host binding, then business code.

The recommended Element Plus entry configures the adapter and infers the model type from defaults.

Describe defaults and rules
Defaults infer model and submit types.
useElForm({ defaults, rules, onSubmit })
Bind the existing Form
One binding wires ref, model, and rules.
<el-form v-bind="form.host">
Drive the lifecycle
Load records, submit, reset, and inspect dirty state.
form.load('edit', detail)

Pick the right layer

vformjs fits teams that want to keep their current UI Form.

A form library decision gets easier when state ownership is explicit.

Option	State and validation	CRUD lifecycle	Good fit when
Native UI Form	Host-owned	Hand-written per screen	The project has only a few simple forms
vformjs	Host validation + shared state	Built in	Admin screens repeat across an existing UI library
vee-validate / Vuelidate	Independent form engine	Application-defined	The team wants field-level headless control
FormKit / FormCreate	Component or schema runtime	Framework-owned	The team wants generated or low-code forms

Do not bind vformjs and another complete form engine to the same fields. Pick one state owner.

A safe place to start

Move one repeated dialog form first.

Keep the business components. Standardize mode, reset, submit, and errors, then decide whether the layer earns a place in the next screen.

Open the guide Browse examples