---
title: "SmartForm"
tagline: "Form engine"
language: "TypeScript"
license: "MIT"
since: "2025"
canonical: "https://xraph.com/work/smartform"
---

# SmartForm

Forms defined as data instead of code: 25-plus field types, conditional visibility and enablement, cascading options loaded from an API, and validation rules that can depend on other fields. A Go builder produces the definition, a React renderer consumes it.

## Install

```bash
pnpm add @xraph/smartform
```

## What it is

SmartForm defines forms as data rather than code: a Go builder produces the definition, a React renderer consumes it, and the same definition drives validation on both sides.

## What it does

- Over 25 field types, from basic inputs to composite components.
- Conditional rendering and conditional enablement based on other fields' values.
- Field dependencies, including cascading selects.
- Dynamic options loaded from an API endpoint or a custom function.
- Validation rules, built-in and custom, that can depend on other fields.
- Nested fields, arrays and conditional branches for grouping.
- Authentication strategies and direct API integration for form submission.
- Extensible field types, validation rules and functions.

## Why data rather than code

A form defined as data can be stored, versioned, edited by someone who is not a programmer, and rendered by more than one client. Every product I have worked on that started with hand-written forms eventually grew a worse version of this, usually as a JSON blob with no schema and no validation story.

---

*Unpublished draft. Not peer reviewed and not submitted to a venue.*


## Anatomy

- **Schema**: Forms described as data rather than written as components.
- **Validation**: Rules travel with the schema to both ends.
- **Renderer**: One schema, several presentations.

## Constraints and trade-offs

- (decision) Data rather than code, so a form can be changed without a deploy.
- (trade-off) Anything the schema cannot express needs an escape hatch, and escape hatches spread.