DEV Community: yanggmtl

Schema-Driven, Framework-Agnostic Forms: Building a Runtime Engine for React, Vue, Angular & Vanilla JS

yanggmtl — Mon, 30 Mar 2026 15:21:12 +0000

In this article, I explain how to build dynamic, schema-driven forms that work across React, Vue, Angular, and Vanilla JS using a registry-driven runtime engine. The forms fully decouple data, UI, and logic, and support conditional logic, dynamic validation, and plugin extensibility—all without hardcoding components.
You can try it out here: GitHub Repository | Install via npm

In most form systems, even schema-driven ones, logic is still tightly coupled to structure or UI.

The goal of Formitiva is to go further:

Fully decouple data, presentation, and behavior

The Problem with Traditional Separation

Typical systems separate:

data (JSON schema)
UI (components)

But logic often remains:

embedded in schema
hardcoded in components
tied to specific frameworks

This creates hidden coupling.

The Key Idea: Reference, Don’t Embed

Instead of embedding logic:

{
  "field": "email",
  "validatorHandlerName": "emailValidator"
}

The schema only references behavior.

It does not define:

how validation works
how UI renders
how logic executes

The Registry System

All implementations live in a registry:

component registry
validation registry
logic/workflow registry

The registry acts as a lookup system:

string reference → actual implementation

The Runtime Engine

The runtime engine is responsible for:

Parsing schema
Resolving references via registry
Executing logic (validation, conditions)
Delegating rendering

This transforms the system into:

Schema → References → Registry → Runtime Execution

Renderer Abstraction (Framework-Agnostic Design)

The runtime does not render UI directly.

Instead, it delegates to renderer adapters:

React
Angular
Vue
Vanilla JS

Each adapter:

receives abstract UI definitions
maps them to framework-specific components

The Resulting Architecture

You get a layered system:

Schema → declarative intent
Registry → implementation mapping
Runtime → execution engine
Renderer → UI layer

Extensibility Through Plugins

Because everything is resolved via registry:

new components can be added
new validators can be injected
new behaviors can be introduced

Without modifying core logic.

Why This Matters

This architecture enables:

true separation of concerns
cross-framework portability
backend-driven UI
low-code possibilities
long-term scalability

Final Thought

Decoupling isn’t just about separating files or layers.

It’s about removing direct knowledge between parts of the system.

The registry pattern achieves that by introducing controlled indirection at runtime.

That’s what makes Formitiva fundamentally different.

Schema-Driven Forms in React: Comparing RJSF, JSON Forms, Uniforms, Form.io, and Formitiva

yanggmtl — Thu, 12 Mar 2026 14:43:35 +0000

Modern applications often need forms that are dynamic, configurable, and reusable.

Instead of hardcoding forms in JSX, many teams adopt schema-driven forms, where the structure of a form is defined using data.

Several libraries implement this idea, including:

React JSONSchema Form
JSON Forms
Uniforms
Form.io

These tools allow developers to define forms declaratively and generate the UI automatically.

However, they differ significantly in how they separate data, UI, and business logic.

This article compares these approaches and explains why registry-based logic can make schema-driven forms more scalable.

Why Schema-Driven Forms Exist

Traditional React forms often combine multiple responsibilities inside the same component:

data structure
UI rendering
validation logic
submission workflows

For example:

function UserForm() {
  const handleSubmit = (data) => {
    validatePassword(data);
    api.saveUser(data);
  };

  return (
    <form>
      <input name="username" />
      <input name="password" />
    </form>
  );
}

This approach works well for small forms, but it becomes difficult to scale when:

many forms exist across a platform
validation rules must be reused
forms are generated dynamically
domain-specific field types are needed

Schema-driven forms attempt to solve this by defining forms using structured data.

Three Layers of a Form System

A useful way to analyze form libraries is to look at three concerns:

Data

Defines the structure of the form:

fields
data types
constraints

Usually represented as schemas or JSON definitions.

UI

Responsible for rendering inputs:

components
widgets
layouts
design system integration

Logic

Handles behavior such as:

validation
conditional rules
submission workflows
API integration

The key architectural question becomes:

Where does business logic live?

Comparison Overview

Library	Data	UI	Logic	Decoupling
RJSF	JSON Schema	Widgets	Component logic	Medium
JSON Forms	JSON Schema	UI Schema	Rules engine	Medium-High
Uniforms	Schema adapters	Themes	Component logic	Medium
Form.io	JSON definitions	Renderer	Embedded logic	Medium-High
Formitiva	Schema definition	Component registry	Registered logic	High

RJSF

React JSONSchema Form is one of the most popular schema-driven form libraries for React.

It renders forms directly from JSON Schema.

Example:

{
  "type": "object",
  "properties": {
    "username": { "type": "string" },
    "age": { "type": "number" }
  }
}

The form engine maps schema types to UI components.

Strengths

strong JSON Schema support
automatic form generation
customizable widgets

Limitations

Submission logic typically remains inside the React component:

<Form
  schema={schema}
  onSubmit={({ formData }) => api.save(formData)}
/>

This means business logic is still tied to UI components.

JSON Forms

JSON Forms introduces a clearer separation between data and UI.

It uses:

Data Schema (JSON Schema)
UI Schema (layout definition)

Example UI schema:

{
  "type": "VerticalLayout",
  "elements": [
    { "type": "Control", "scope": "#/properties/username" }
  ]
}

Strengths

explicit separation of structure and layout
rule-based UI behavior
framework-agnostic architecture

Limitations

Submission workflows and business logic are usually implemented outside the schema.

Uniforms

Uniforms focuses on schema adapters.

It supports multiple schema systems:

JSON Schema
GraphQL
SimpleSchema

Example usage:

<AutoForm schema={schema} onSubmit={saveUser} />

Strengths

flexible schema support
good integration with UI frameworks
minimal boilerplate

Limitations

Validation and workflows are still mostly handled in React logic.

Form.io

Form.io is closer to a complete form platform.

Forms are defined entirely in JSON:

{
  "components": [
    {
      "type": "textfield",
      "key": "username"
    }
  ]
}

Strengths

visual form builder
dynamic forms
built-in conditional logic

Limitations

Logic is usually embedded inside the form definition itself, which can reduce reuse across forms.

Architecture Comparison

Different libraries organize form responsibilities differently.

RJSF
Schema → Renderer → Component Logic

JSON Forms
Schema + UI Schema → Renderer → Rules

Uniforms
Schema Adapter → UI Theme → Component Logic

Form.io
Form Definition → Renderer → Embedded Logic

Most approaches successfully separate data and UI, but logic often remains tied to forms or components.

A Registry-Driven Approach

Formitiva takes a different approach.

Instead of embedding logic in schemas or components, it introduces a registry system.

Schemas reference behaviors declaratively:

const definition = {
  name: "user_information",
  validationHandlerName: "user:passwordMatch",
  submitHandlerName: "user:userSubmission",
  properties: [
    {
      name: "username",
      type: "text"
    }
  ]
};

The actual implementations are registered separately:

registerFormValidationHandler(
  "user:passwordMatch",
  passwordMatchValidator
);

registerSubmissionHandler(
  "user:userSubmission",
  submitUserData
);

Formitiva Architecture

+----------------------+
|      Form Schema     |
|      (Data Layer)    |
+----------------------+
           |
           v
+----------------------+
|       Registry       |
| (UI + Logic Mapping) |
+----------------------+
           |
           v
+----------------------+
|       Renderer       |
|       (React UI)     |
+----------------------+

This architecture separates:

data definitions
UI components
business logic

Why Registration-Based Logic Helps

The registry pattern enables several advantages.

Reusable Validation

Validators can be reused across many forms.

Example:

user:passwordMatch
geo:coordinateValidator
payment:cardValidator

Reusable Workflows

Submission logic becomes reusable:

API integration
workflow orchestration
event triggers

Domain-Specific Field Types

Custom fields can be registered once:

registerComponent("point2d", PointInput)

Any schema can use that type.

Dynamic Form Platforms

The architecture works well for:

dynamic forms from APIs
low-code platforms
domain-specific applications
large systems with many forms

When to Use Each Approach

Different libraries work best in different situations.

RJSF

Best for:

simple JSON Schema forms
rapid prototyping

JSON Forms

Best for:

dynamic UI layouts
rule-based behavior

Uniforms

Best for:

projects using schema adapters
strong design system integration

Form.io

Best for:

full form platforms
visual form builders

Formitiva

Best for:

reusable form ecosystems
dynamic form platforms
domain-specific workflows
large applications with many forms

Final Thoughts

Schema-driven forms are a powerful way to build dynamic user interfaces.

Libraries like RJSF, JSON Forms, Uniforms, and Form.io already separate form structure from UI rendering, making forms easier to maintain.

However, business logic is often still tied to components or form definitions.

A registry-based architecture pushes this separation further by treating validation, workflows, and UI components as independent, reusable modules.

This approach makes schema-driven forms not just a UI convenience, but a foundation for scalable form platforms.

Decouple Data, UI and Logic in React Forms Using the Formitiva Registry System

yanggmtl — Wed, 11 Mar 2026 17:38:24 +0000

Most React forms mix several responsibilities in the same place:

data definition
UI components
validation logic
submission workflows

At first this feels natural. A form component renders inputs, validates data, and submits the data to an API.

But as applications grow, this approach becomes harder to maintain. Forms start to:

reuse the same validation rules
trigger shared workflows
appear dynamically from a backend
evolve independently from UI implementations

When data structure, UI rendering, and business logic are tightly coupled inside React components, even small changes can ripple across the codebase.

Why Traditional React Forms Don't Scale

The main challenge is that forms often become mini applications inside a single React component.

Over time, the component starts handling multiple responsibilities:

defining the data structure
rendering UI inputs
performing validation
coordinating submission workflows
integrating with APIs

This works for small forms, but the complexity grows quickly when applications require:

dozens or hundreds of forms
reusable validation logic
domain-specific field types
dynamic forms generated from APIs or databases
visual form builders or low-code systems

When UI, data, and business logic are tightly coupled, forms become harder to reuse, extend, or generate dynamically.

This is the problem Formitiva tries to solve.

Formitiva introduces a registry system that separates form data, UI components, and business logic. Instead of embedding validation and submission logic inside form components, those behaviors are registered once and referenced by schema definitions.

Formitiva in One Sentence

Formitiva lets you define forms as schema data while registering the UI and logic those schemas should use.

A form definition can stay small and declarative:

const userInformationDefinition = {
  name: 'user_information',
  version: '1.0.0',
  displayName: 'User Information',
  validationHandlerName: 'user:passwordMatch',
  submitHandlerName: 'user:userDataSubmission',
  properties: [
    {
      name: 'userName',
      displayName: 'User Name',
      type: 'text',
      defaultValue: '',
      required: true,
    },
    {
      name: 'email',
      displayName: 'Email',
      type: 'email',
      defaultValue: '',
    },
    {
      name: 'password',
      displayName: 'Password',
      type: 'password',
      defaultValue: '',
      validationHandlerName: ['user', 'passwordValidator']
    },
    {
      name: 'confirmPassword',
      displayName: 'Confirm Password',
      type: 'password',
      defaultValue: '',
      validationHandlerName: ['user', 'passwordValidator']
    }
  ],
};

This definition describes:

the fields in the form
the field types
the validation and submission handlers

But it does not contain:

React components
validation functions
API calls
workflow logic

The schema only describes intent.

The actual behavior is resolved through the registry system.

Separating Data, UI, and Logic

Formitiva intentionally separates forms into three independent concerns:

At a high level, the architecture looks like this:

+----------------------+
|      Form Schema     |
|      (Data Layer)    |
+----------------------+
           |
           v
+----------------------+
|       Registry       |
| (UI + Logic Mapping) |
+----------------------+
           |
           v
+----------------------+
|       Renderer       |
|       (React UI)     |
+----------------------+

Data (Form Definition)

The schema describes:

fields
data types
constraints
references to behaviors

It represents the data model of the form, which means it can come from:

a database
a backend service
a CMS
a visual form builder
configuration files

Because definitions are pure data, they are portable and easy to version.

UI (Field Components)

The UI layer is responsible only for rendering inputs and collecting user input.

Field components are mapped to field types through the registry.

The schema never references a specific React component.

Logic (Validation and Workflows)

Business logic such as:

validation rules
submission workflows
button actions

is implemented separately and registered with the system.

Schemas only reference logic by name, not by function implementation.

This separation allows forms to evolve without tightly coupling the layers.

What the Registry System Does

The Formitiva registry is a central lookup system that connects schema references to real implementations.

Instead of embedding logic directly inside form definitions or components, you register behaviors once and reference them by name.

The registry supports registering:

field validation handlers
form validation handlers
submission workflows
button actions
custom field components
plugins that bundle multiple extensions

At runtime, Formitiva reads the schema and resolves those references through the registry.

This design is what allows form data, UI, and business logic to remain independent.

Registering Field and Form Validation

Validation is one of the first things that tends to get mixed into UI components.

For example, many form implementations attach validation logic directly to inputs or inside React components.

Formitiva moves validation logic into the registry.

You can register validation handlers like this:

registerFormValidationHandler(
  'user:passwordMatch',
  passwordMatchValidator
);

Then the schema references those handlers:

{
  "validationHandlerName": "user:passwordMatch"
}

This approach has several advantages:

validation logic is reusable across many forms
schemas remain simple and declarative
validation is no longer tied to UI components

The schema only says which validator to use, while the registry provides the implementation.

Registering Submission Workflows

Submission logic is another area where business logic often leaks into UI components.

In many React applications, the form component contains API calls or workflow orchestration inside its submit handler.

Formitiva separates this by registering submission handlers.

registerSubmissionHandler(
  'user:userDataSubmission',
  userDataSubmissionHandler
);

The schema then references that handler:

{
  "submitHandlerName": "user:userDataSubmission"
}

This keeps workflows reusable and independent from the UI.

Submission handlers can perform tasks such as:

calling APIs
triggering backend workflows
saving data
dispatching events

Most importantly, this business logic no longer lives inside React components.

The form component simply renders the UI, while the submission handler controls what happens after submission.

Registering Custom Field Components

The most powerful extension point in the registry system is custom field types.

Schemas describe what type of data a field represents, but they do not define how the field is rendered.

Instead, the registry maps field types to React components.

Registering a Custom Field Type

For example, you can register a new field type called point2d:

registerComponent('point2d', Point2DInput);

Once registered, any schema field with this type will be rendered using the Point2DInput component.

{
  "type": "point2d"
}

This allows schemas to remain UI-agnostic, while the registry determines how each field should appear.

Registering a Type Validator

A field type can also have a type-level validator that checks whether the data matches the expected format.

For example, a built-in int type validator might check:

whether the value is a valid integer
whether it satisfies constraints such as min and max

Custom types can register their own validator as well:

registerFieldTypeValidationHandler(
  'point2d',
  pointValidator
);

The validator ensures that values for the point2d type follow the expected structure (for example [x, y] coordinates).

Registering a type validator is optional. If a custom type does not require additional validation, it can be omitted.

Why This Matters

This design allows you to create domain-specific field types while keeping schemas clean and declarative.

It also makes integration with design systems easier, because schemas only reference field types, not specific UI components.

As a result:

schemas describe data
components handle presentation
validators enforce data correctness

Each concern remains independent, which keeps forms easier to maintain and extend.

Organizing Extensions with Plugins

As your form platform grows, you may want to group related extensions together.

Formitiva supports this through plugins.

A plugin can bundle components, validators, and submission handlers into a single package.

const PointPlugin = {
  name: 'point_plugin',
  version: '0.1.0',
  components: {
    point2d: Point2DInput,
  },
  fieldCustomValidators: {
    point2d: {
      nonNegativePoint,
    },
  },
  formValidators: {
    'point2d:regionValidator': regionValidator,
  },
  submissionHandlers: {
    'point2d:alertSubmission': alertSubmissionHandler,
  },
};

registerPlugin(PointPlugin);

This keeps extensions organized instead of scattering logic across different parts of the application.

The Formitiva Architecture

A helpful way to understand Formitiva is to think of it as three layers.

Definition
     ↓
Registry
     ↓
Renderer

Definition (Data Layer)

The schema describes the data structure of the form.

It can come from code, APIs, databases, or visual builders.

Registry (Logic & UI Mapping)

The registry maps schema references to implementations such as:

validators
workflows
components

Renderer (UI Layer)

The renderer converts the definition into a working form UI at runtime.

Because of this architecture:

schemas remain pure data
UI components stay focused on rendering
business logic stays reusable

When This Architecture Works Best

The registry-first approach becomes especially valuable when:

forms are stored in databases or APIs
many forms exist across a platform
domain-specific field types are required
submission workflows are reused
a visual form builder or low-code system is needed

If your application only has a few static forms, traditional JSX-based forms may be enough.

But once forms become a platform capability rather than just page components, separating UI and business logic becomes much more important.

Final Thoughts

Separating UI and business logic in forms is harder than it first appears.

In many React applications, form components gradually accumulate responsibilities:

defining data structures
rendering inputs
validating data
calling APIs
coordinating workflows.

This works for small forms, but it becomes difficult to scale when forms need to be reused or dynamically generated.

Formitiva addresses this with its registry system.

Instead of embedding logic inside form components, Formitiva lets you register validation handlers, submission workflows, and field components separately, while schemas define the data structure and reference those behaviors declaratively.

This separation of data, UI, and logic keeps schemas portable while making UI components and business logic reusable.

And that separation is what turns schema-driven forms from a nice idea into a practical architecture for real applications.

Currently Formitiva supports React forms, while Vue and Angular integrations are currently in testing.

Stop Hardcoding React Forms: Build Dynamic Schema-Driven Forms with Formitiva

yanggmtl — Fri, 06 Mar 2026 16:34:42 +0000

React developers write a lot of forms.

Contact forms. Admin panels. Settings pages. Onboarding flows.

And in most React apps, we build them the same way:

Write JSX
Wire up validation
Connect submission logic
Repeat

It works… until the form needs to change without redeploying.

What happens when:

Forms need to change without redeploying
Non-frontend teams must configure fields
Your backend drives the structure
You support multi-tenant platforms

Suddenly, hardcoded JSX forms become a bottleneck.

That’s where Formitiva comes in.

What Is Formitiva?

Formitiva/React is a schema-driven form platform for React.

Instead of building forms directly in JSX, you define them as JSON schemas and render them at runtime.

Your form definition can live:

In your source code
In a database
Inside a CMS
Behind an API

Formitiva reads the definition and renders the entire form automatically.

No handcrafting every <input />.
No redeploy required for structural changes.

Think of It as a Runtime Form Engine

Formitiva isn’t trying to replace traditional form libraries like Formik or React Hook Form.

Those tools are fantastic for static, code-defined forms.

Formitiva is different.

It is:

Schema-first – Forms are defined as structured JSON
Runtime-configurable – Update structure without redeploying
Backend-friendly – Store, version, and serve form definitions
Portable – Reuse forms across multiple apps

It’s built for dynamic environments where form structure is data — not UI code.

Why Schema-Driven Forms Matter

Most React form libraries assume:

The structure is mostly static
Developers define fields in JSX
Structural changes require a redeploy

That’s fine for marketing forms or simple CRUD screens.

But in:

SaaS platforms
Enterprise systems
Multi-tenant applications
CMS-driven architectures

Those assumptions quickly become limitations.

With Formitiva, the UI becomes a rendering layer. The structure lives in data.

Core Mental Model

Formitiva is built around a few key concepts:

Definition

The JSON schema describing:

Fields
Labels
Validation rules
Conditional logic
Behavior
Instance

The values object (for editing existing data or preloading state).

Renderer

The React component that transforms a definition into a live form.

Registries

Extension points for:

Custom components
Custom validators
Submission handlers
Button actions

i18n Support

Translation helpers built into the system.

This separation keeps things clean:

Structure → Data
Rendering → Engine
Customization → Registries

Getting Started in 2 Minutes

Install:

npm install @formitiva/react

Create a form definition:

import { Formitiva } from '@formitiva/react';

const definition = {
  name: 'contactForm',
  version: '1.0.0',
  displayName: 'Contact Form',
  properties: [
    { name: 'name', type: 'text', displayName: 'Name', required: true },
    { name: 'email', type: 'email', displayName: 'Email', required: true },
    { name: 'message', type: 'multiline', displayName: 'Message' }
  ]
};

export default function App() {
  return <Formitiva definitionData={definition} />;
}

That’s it.

No JSX per field.
No manual wiring.
The form renders entirely from your schema.

Handling Submissions

Just pass an onSubmit handler:

<Formitiva
  definitionData={definition}
  onSubmit={(definition, instanceName, values) => {
    console.log(values);
  }}
/>

You can also register named submission handlers — which is powerful when your backend decides how a form should be processed.

Perfect for API-driven workflows.

When Should You Use Formitiva?

Formitiva shines when forms are:

Generated from backend data
Frequently updated
Reused across multiple applications
Managed by low-code teams
Stored and versioned in a database
Highly dynamic and rule-driven

If your forms are simple and static, traditional libraries are great.

If your forms are part of a configurable platform — Formitiva becomes very interesting.

Bonus: Low-Code Builder

Formitiva also includes a drag-and-drop Builder.

This enables:

Designers to create forms visually
Product teams to configure fields
Non-frontend contributors to maintain workflows

While developers still retain full control through registries and customization hooks.

The Big Idea

Most React form libraries treat forms as components.

Formitiva treats forms as data.

That shift unlocks:

Runtime configurability
Backend-driven workflows
Cross-application portability
Cleaner separation of concerns

Define once. Render anywhere. Update without redeploying.

React-ready. Vue support in testing.

Try Formitiva

Builder: Try the Form Builder
Website: formitiva.com
GitHub: github.com/formitiva/react
npm: npmjs.com/package/@formitiva/react

If you're building configurable systems, admin platforms, or dynamic SaaS products, schema-driven forms can unlock a much more flexible architecture.