Form

​

What it is

Not a component with its own props — a set of theme overrides applied to the underlying primitives every field is built from: FormControl, FormGroup, and FormLabel. Label color and weight, disabled-label spacing, and helper-text typography are decided here, once, so every field page in this category inherits them rather than restating them. The primitives this page themes are deprecated for direct use. Titan re-exports FormControl and FormLabel from a source module named, verbatim, DeprecatedFormControls, and their own JSDoc says so directly: “Use FormInput for label + input + helper/error text patterns.” If you are assembling a labeled field by hand from these pieces, you are using the retired path.

​

Exports

This page has no exports of its own. Two things share its name in ways worth being precise about: The current, real way to compose a labeled field is FormInput — a single component that renders one of six input types and handles the label, helper text, error state, and accessibility wiring uniformly. It is not this page’s export, and it does not get its own page — see Composing a field below for where each type is documented.

​

Composing a field

Verified directly from FormInput’s own source and its published Storybook stories, three of which are explicit, named anti-patterns: Switch has no corresponding type. FormInput’s six types do not include one for a binary toggle — see Switch’s open issues for what that means for composing a labeled Switch field today.

​

Live example

No Storybook story exists for this page — there is no Form component to demonstrate. See FormInput’s own stories on each field’s page instead.

​

Choose Form when

Never, directly. This page exists to be linked to, not reached for. If you are building a labeled field, go to that field’s own page and its type row above.

​

Choose something else when

​

Anatomy

Not applicable — this page has no component structure of its own. Its effect is the theming inherited by FormControl, FormGroup, and FormLabel wherever a field renders them.

​

Variants, sizes, and states

Not applicable — see each field’s own page.

​

Edge and failure states

Not applicable — see each field’s own page.

​

Tokens

Verified directly from Form.overrides.ts — no per-component token emitter exists yet for this concept, so this table is hand-confirmed rather than generated.

​

Composition

Every field page in this category (Input, Select, Checkbox, Radio, Switch, DatePicker, FileUpload) inherits this theming through the underlying primitives it wraps. FieldLabel’s own component page covers the visible label element itself in more depth; this page covers the FormControl/FormGroup container theming around it.

​

Content

Not applicable — see each field’s own page for label and helper-text copy rules.

​

Accessibility

Not applicable on its own — the accessibility behavior this page’s theming supports (label association, disabled-state opacity, error-text color) is exercised and documented on each field’s own page.

​

Constraints

​

Known issues

​

Why it works this way

Theming the shared primitives once, separately from any single field’s page, is what lets every field page stay silent about label color and helper-text type. If Input’s page had to restate what Select’s page also states about label styling, the two would drift the first time either was edited alone. Centralizing it here — even without a component of its own to hang it on — is the same reasoning as Foundations existing separately from Components.

​

Status

​

Related

• FormInput’s usage — 66 usages across 19 applications, the most-adopted way to compose a field in this category
• Input · Select · Checkbox · Radio · Switch
• FieldLabel — the visible label element itself