DEV Community: Cla

mobx-react-form is now mobx-formkit

Cla — Sun, 16 Aug 2026 11:05:00 +0000

The mobx-react-form package — after 273 releases ending with 7.1.0 — is
now published on npm as mobx-formkit. The old package name is marked as
deprecated on the npm registry: anyone installing mobx-react-form today
gets a deprecation notice pointing to mobx-formkit, with no breaking change
for existing installs already pinned to the old name.

The new package is a fresh 1.0.0 release on top of the exact same codebase
(7.1.0 API), under a name that matches what the library actually is:
MobX form state management, not a React-only project. The GitHub repo,
the demo app and the documentation moved along:

	Before	After
npm install	`npm i mobx-react-form`	`npm i mobx-formkit`
import (CJS / ESM)	`import MobxReactForm from 'mobx-react-form'`	`import MobxFormkit from 'mobx-formkit'`
UMD globals	`MobxReactForm`, `MobxReactFormValidator*`	`MobxFormkit`, `MobxFormkitValidator*`
Docs	`foxhound87.github.io/mobx-react-form`	`foxhound87.github.io/mobx-formkit`
Live demo	old URL → 404	`foxhound87.github.io/mobx-formkit-demo`
Repo	`foxhound87/mobx-react-form`	`foxhound87/mobx-formkit`

APIs are identical. The only breaking surface is UMD: bundle filenames and
script-tag globals changed from MobxReactForm* to MobxFormkit* — update
your <script src> paths and global references. npm imports and ESM
consumers are unaffected beyond the package name. Old docs URLs under
/mobx-react-form/ now return 404.

Why the rebrand — the library, not the framework

The core of the library depends only on MobX (plus lodash-es) and knows
nothing about React, Vue or any DOM. Form state — values, errors, dirty and
touched flags, validation — lives in observable Form / Field instances,
so any reactive consumer can render it:

React (official): mobx-react / mobx-react-lite with observer(); field props map to component props via the bundled Bindings (key rewriters or function-based templates): Material UI, Ant Design, React Aria, Headless UI, React Select, React Widgets, and more.
Vue 3: mobx-vue-lite (<Observer>, Composition API).
Lit: @adobe/lit-mobx.
Angular: mobx-angular (*mobxAutorun).
Solid: mobx-solid (community).
Octane: @octanejs/mobx (mobx-react-lite compatible surface).
Vanilla JS: plain autorun / reaction — no framework at all.

In other words: the library is UI-agnostic and not opinionated about React.
The package splits into a compact core plus separate subpaths — validators
(mobx-formkit/validators/*, mobx-formkit/lib/validators/*), a composer
for multi-form wizards — plus a dedicated devtools package. Form state lives
in pure MobX; bindings live wherever your UI does.

Validation in 2026

Eight validation drivers share one uniform lifecycle — define fields once,
swap or combine plugins without touching field definitions:

Driver	Library	Mode	Notes
VJF	vanilla functions	sync + async	rules as plain functions
DVR	validatorjs	sync + async	declarative rules string
AJV	ajv	sync + async	JSON Schema
YUP	yup	sync + async	promise-based
JOI	joi	sync	schema objects
ZOD	zod	sync	zod v3.25+ and v4; use `zod/v4/core` for smaller bundles
VALIBOT	valibot	sync	new in 7.1.0 — no `package` prop needed, errors per-path incl. nested/array
VINEJS	@vinejs/vine	async	new in 7.1.0 — promise-based, requires a Vine instance + schema

Notable additions of the final 7.1.0 cycle: VALIBOT is zero-config
(valibot({ schema }) — no external package prop) and reports per-field
errors for nested and array paths automatically; VINEJS is async by
design (await form.validate()) and maps error.messages dot-notated paths
onto the right fields. All drivers support the extend callback
({ validator, form }), and both contracts — sync validateSync and async
validate / submit promises — are intact. Core Form / Field methods
(validate, validateSync, clear, reset, $form, ...) are unchanged.

import valibot from 'mobx-formkit/lib/validators/VALIBOT';
import vinejs from 'mobx-formkit/lib/validators/VINEJS';
import vine from '@vinejs/vine';
import * as v from 'valibot';

const plugins = {
  valibot: valibot({ schema: v.object({ email: v.pipe(v.string(), v.email()) }) }),
  vinejs: vinejs({ package: vine, schema: vine.object({ age: vine.number().min(18) }) }),
};

new Form({ fields }, { plugins });

The library ships 1611 unit/integration tests passing, with 95.89% statement
coverage (86.69% branches), built on TypeScript ^5.9.

Migration path

Install: npm i mobx-formkit.
Swap imports: replace every mobx-react-form import and require with mobx-formkit. That's it for npm-based consumers — APIs are identical.
UMD consumers: update bundle filenames and globals from MobxReactForm* to MobxFormkit* (this is the one breaking change).
Bookmark the new docs (old URLs 404) and check the migration guide in the documentation.

Resources

npm: mobx-formkit - mobx-react-form (deprecated)
GitHub: foxhound87/mobx-formkit
Docs: https://foxhound87.github.io/mobx-formkit/
Live demo: https://foxhound87.github.io/mobx-formkit-demo/
DevTools: foxhound87/mobx-formkit-devtools
Community: Discord

The Agentic Skills of mobx-formkit: How AI Assistants Now Master React Forms

Cla — Tue, 04 Aug 2026 12:34:00 +0000

Form handling in React has always been a manual, repetitive, and error-prone affair. For years, mobx-react-form has solved the runtime side of that problem — reactive form state, validation, bindings — with a clean, declarative API. But 2025 changed what "solving a problem" means: AI coding assistants now write large chunks of our forms for us. The quality of that generated code, however, depends entirely on the quality of the context the model is given.

Enter agentic skills: packaged, installable instruction sets that teach AI assistants the precise idioms, APIs, and patterns of a library before they write a single line of code. The foxhound87/skills repository brings this to mobx-formkit — the successor of mobx-react-form — with a curated collection of 15 specialized skills, one for every major area of the library.

What Are Agent Skills?

Agent skills are essentially prompt-level documentation that lives on the agent's side. They contain the kind of knowledge a senior developer has internalized: exact method signatures, edge cases, the right pattern versus the working pattern. When an AI assistant is asked to build a multi-step form or wire up async validation, it doesn't have to guess — it loads the relevant skill and follows battle-tested guidance.

Skills for mobx-formkit are distributed via skills.sh and can be installed in seconds:

# Install the full collection
npx skills add https://github.com/foxhound87/skills --all

# Install a single skill
npx skills add https://github.com/foxhound87/skills --skill mobx-formkit-validation

# Install for a specific agent (e.g. opencode)
npx skills add https://github.com/foxhound87/skills -a opencode --all

The Skill Collection: From Core to Advanced

The 15 skills mirror the mental model of the library itself: a core API layer, a set of field-definition skills, validation, and then a cluster of advanced capabilities.

Core Skills

Skill	What it teaches the agent
mobx-formkit-api	Installation, `Form`/`Field` constructor, full property and method reference, helpers, event handlers. The prerequisite for everything else.
mobx-formkit-flat	Flat field definitions — unified, separated, and mixed modes, field properties, patterns.
mobx-formkit-nested	Nested and array fields — dot notation, array notation, dynamic add/remove, `ArrayMap`, field traversal.
mobx-formkit-validation	All six validation plugins (DVR, VJF, SVK, YUP, JOI, ZOD), async and cross-field validation, validation hooks.
mobx-formkit-bindings	Field bindings — default rewriter/template, custom bindings, `$try`, per-field mapping, UI framework adapters.
mobx-formkit-multi-step	Multi-step wizard forms — nested groups, per-step validation, navigation, review screens.

Advanced Skills

Skill	What it teaches the agent
mobx-formkit-events	Event hooks and handlers — `onInit`, `onChange`, `onFocus`, `onBlur`, `onSubmit`, `onSuccess`, `onError`, key events.
mobx-formkit-observers-interceptors	MobX observers and interceptors — observing field changes, intercepting mutations, rejecting/modifying values, disposers.
mobx-formkit-computed	Reactive computed props and `autorun` — computed field values, autorun-derived totals, row calculations.
mobx-formkit-composer	The forms composer — orchestrating multiple `Form` instances with batch validate/submit/clear/reset.
mobx-formkit-converters	Input/output converters — transforming values between input and store, per-field and separated mode.
mobx-formkit-file-upload	File upload fields — `type: file`, drag-and-drop zones, `onDrop` hooks, `FileList` access, validation.
mobx-formkit-sortable	Sortable arrays — `move()`, `ArrayMap` reordering, drag-and-drop with `@dnd-kit`, up/down buttons.
mobx-formkit-extend	Extending `Form` and `Field` classes — custom field classes, `makeField()`, generic and specific extension.
mobx-formkit-options	Form and field options — validation timing, error display, strict modes, debounce, data retrieval.

What the Skills Actually Contain

A skill isn't a vague prompt — it's structured, actionable reference material. The mobx-formkit-validation skill, for example, documents all six validation drivers with ready-to-use setup snippets:

// ZOD — TypeScript-first schema validation
import zodValidator from 'mobx-formkit/lib/validators/ZOD';
import { z } from 'zod';

const schema = z.object({
  email: z.string().email(),
  password: z.string().min(6),
});

const plugins = {
  zod: zodValidator({ package: z, schema }),
};

But more importantly, it encodes the non-obvious knowledge — the things that trip up both humans and AI models:

Async validation: returning Promises from VJF validators, registerAsync for DVR, async onChange hooks that call field.invalidate().
Cross-field validation via the related property, so changing password re-validates passwordConfirm.
The full validation-options matrix: validateOnInit, validateOnBlur, showErrorsOnChange, validationDebounceWait, stopValidationOnError, and how per-field options override form-level ones.
Plugin ordering with validationPluginsOrder when mixing drivers.
Programmatic invalidation with field.invalidate(msg, deep, async).

That last category is the real value of agentic skills: the difference between code that works and code that's idiomatic.

Why This Matters for AI-Generated Code

Anyone who has used an AI assistant to scaffold a form knows the failure modes: a model that trained on generic form libraries will happily generate useState-based controlled inputs, invent non-existent methods, or skip the onError hook entirely. The generated code compiles, renders, and almost works — until you hit validation.

Skills eliminate the guesswork. The mobx-formkit-api skill alone encodes the entire architecture — Form → fields: ArrayMap<Field> → state/bindings/validator — plus the full method table, so a model asked to "add a reset button" reaches straight for form.reset() instead of re-implementing state management.

There's also a practical benefit beyond correctness: faster iteration. Instead of prompting an agent with context and then debugging the result, the skill gives it the right primitives up front. Fewer rounds of "no, that's not how the API works."

The Library's Design Makes This Easy

mobx-formkit is unusually well-suited for agentic skills because of its consistency:

Everything is reactive — form and field properties are MobX observables, and observer()-wrapped components re-render automatically. Agents just need to know which properties are computed (isValid, isDirty, isPristine, hasError...) versus editable.
One selector for everything — form.$('path') / form.select() works for flat, nested, and array fields with the same dot-notation syntax.
Declarative validation — rules live in field definitions, so agents can express complex logic as configuration instead of imperative code.
Uniform extension points — plugins(), hooks(), bindings(), and class extension via makeField() cover almost every customization need.

When an API is this regular, a skill can document a small number of patterns that cover a very large space of use cases. That's precisely what makes the skill set effective.

Getting Started

Install the skills for your agent of choice (opencode, Claude Code, Cursor, and others are supported by skills.sh).
Start with the core trio: mobx-formkit-api, mobx-formkit-nested, and mobx-formkit-validation — they cover the 80% use case.
Bring in the rest as needed: reach for multi-step, sortable, or file-upload when the requirement appears.
Let the agent load the skill when prompting — e.g., "using the mobx-formkit-validation skill, add cross-field validation for the password fields."

The repository is MIT-licensed and actively maintained by foxhound87 (the author of mobx-formkit — formerly mobx-react-form — himself), so the skills track the library's actual behavior — not a stale approximation of it.

Conclusion

Agent skills represent a shift in how we document libraries: from documentation you read, to documentation the AI reads — so the AI can write code as if it had read the docs itself. With 15 skills spanning the full API surface of mobx-formkit (formerly mobx-react-form), the foxhound87/skills repository turns AI assistants into competent React form developers out of the box.

The era of AI generating useState-spaghetti for forms is over — at least for anyone willing to spend 30 seconds installing a skill.

Repository: github.com/foxhound87/skills · MIT License · Install via npx skills add https://github.com/foxhound87/skills --all

📚 Documentation: mobx-formkit docs
🚀 Live Demo: mobx-formkit-demo · demo code

Why mobx-react-form Is the Best Form Library You're Not Using

Cla — Sat, 06 Jun 2026 20:00:00 +0000

If you build forms in React, you've probably tried Formik, React Hook Form, or final-form. They're good. But if you deal with complex, deeply nested, multi-step forms — the kind that make you question your life choices — there's a better tool.

mobx-react-form combines MobX reactivity with a powerful form state engine. Here's why it deserves your attention.

1. Nested Fields Without the Pain

Real forms aren't flat. Take an invoice: you have a customer section, a shipping address, and a variable number of products, each with name, quantity, and price.

MRF handles this natively:

const fields = [
  'customer.name',
  'customer.email',
  'shipping.address',
  'shipping.city',
  'shipping.zip',
  'products',
  'products[].name',
  'products[].quantity',
  'products[].unitPrice',
];

Each path becomes an observable field with its own validation, errors, and dirty tracking. No flattening. No normalization. The values serialize back to exactly the structure your API expects:

{
  "customer": { "name": "...", "email": "..." },
  "shipping": { "address": "...", "city": "...", "zip": "..." },
  "products": [
    { "name": "Widget A", "quantity": 2, "unitPrice": 19.99 }
  ]
}

And with v6.15, errors bubble up automatically:

const form = new MobxReactForm({ fields }, {
  options: { bubbleUpErrorMessages: true }
});

// When products[0].product is empty, this just works:
{form.error && <ErrorBanner message={form.error} />}

2. Validation Plugins — Bring Your Own

MRF doesn't lock you into one validator. It supports 6 validation plugins out of the box:

Plugin	Package	Style
DVR	validatorjs	Declarative rules (`'required
VJF	Custom functions	{% raw %}`(value) => [isValid, message]`
ZOD	zod	Schema-based
YUP	yup	Schema-based
JOI	joi	Schema-based
SVK	ajv	Schema-based

Use DVR for simple fields and ZOD for complex cross-field validation — in the same form:

plugins() {
  return {
    dvr: dvr({ package: validatorjs }),
    zod: zod({ package: z, schema: invoiceSchema }),
  };
}

Define a Zod schema for your entire form and get both client-side validation and TypeScript types from one source:

const invoiceSchema = z.object({
  customer: z.object({
    name: z.string().min(2),
    email: z.string().email(),
  }),
  products: z.array(z.object({
    name: z.string().min(1),
    quantity: z.number().min(1),
    unitPrice: z.number().positive(),
  })).min(1),
});

3. Full TypeScript Generics (v6.13)

If you're on TypeScript, MRF now offers end-to-end type safety:

interface InvoiceForm {
  customer: { name: string; email: string };
  shipping: { address: string; city: string; zip: string };
  products: Array<{ name: string; quantity: number; unitPrice: number }>;
}

const form = new MobxReactForm<InvoiceForm>({ fields });

form.$('products[0]').$('name'); // Field<string> — fully typed
form.values();                        // InvoiceForm — fully typed
form.$('customer').$('name').set('Acme Corp'); // type-safe setter

Plus PathsOf<T> for autocomplete:

form.$('ship') // → editor suggests: 'shipping.address' | 'shipping.city' | 'shipping.zip'

No more guessing field paths. No more runtime errors from typos.

4. Dynamic & Array Fields

Need to add products dynamically? Remove a shipping address from a list? Built in.

// Add a product
form.$('products').add({
  product: 'New Product',
  quantity: 1,
  unitPrice: 0,
});

// Remove the second product
form.$('products').del(1);

// Reorder (new in v6.14 with ArrayMap)
form.$('products').move(0, 2);

Arrays, nested arrays, dynamic field creation — MRF handles all of it with MobX reactivity. Each item gets its own validation lifecycle, dirty tracking, and error state.

5. Composer — Multi-Form Orchestration

Have independent forms that need to submit together? The composer() function coordinates validation across forms:

const checkout = composer({ billing, shipping, payment });

checkout.validate().then(({ valid, errors, values }) => {
  if (valid) {
    submitOrder({
      ...values.billing,
      shipping: values.shipping,
      payment: values.payment,
    });
  } else {
    // errors is keyed by form name: { billing: {...}, shipping: {...}, payment: {...} }
    showValidationSummary(errors);
  }
});

Perfect for checkout flows, multi-tab dashboards, and wizard-style UIs where each step is an independent form.

6. UI Library Agnostic

MRF works with every major UI library — and doesn't force you to pick one:

Material UI
Ant Design
React Aria
Headless UI
React Widgets
React-Select
Plain HTML

Each gets a thin binding layer. The form logic stays the same whether you render with MUI TextFields or raw <input> elements.

// Works the same regardless of UI library
<form onSubmit={form.onSubmit}>
  <Input field={form.$('customer.name')} />
  <Input field={form.$('customer.email')} />
  <button type="submit">Save</button>
</form>

Swap the Input component from MaterialTextField to AntdInput to SimpleInput — the form state doesn't care.

7. Built for Production, Maintained for Years

MRF has been powering production forms for 8+ years. It has 1.1k+ GitHub stars, and the latest releases (June 2026) brought the most requested features:

v6.15 — Error bubbling in nested forms
v6.14 — ArrayMap with predictable ordering and drag-and-drop support
v6.13 — Full TypeScript generics, strict null checks, path autocomplete
v6.12 — Custom validation type inference, YUP .ref() support
v6.11 — Full null values support

Each release was driven by real production needs, not hypothetical use cases.

The Bottom Line

Scenario	MRF	Alternatives
Simple login form	✅ Overkill but works	✅ Great fit
Deeply nested fields (invoice, order, profile)	✅ Native support	❌ Requires flattening
Dynamic arrays (add/remove/reorder)	✅ Built-in	❌ Manual state mgmt
Multi-form validation (checkout, wizard)	✅ Composer	❌ Custom orchestration
Validation plugins (DVR/ZOD/YUP/JOI)	✅ 7 plugins	❌ Usually 1-2
TypeScript generics + path autocomplete	✅ v6.13+	❌ Limited
Error bubbling in nested forms	✅ v6.15+	❌ Manual recursion
UI library flexibility	✅ Any library	✅ Any library

If you build forms beyond a login page — invoices, checkouts, multi-step registrations, admin panels with dynamic sections — give MRF a try. It handles the complexity so you don't have to.

npm install --save mobx-react-form

Try the live demo | GitHub | Docs