Field authoring
A field component in BlueForm is a plain React component with one responsibility: render a piece of UI that reflects and mutates a single form value. It does not manage state, does not know about other fields, and does not handle validation — the engine takes care of all of that before the component renders.
This separation is what makes field components reusable. Write an InputField once, wire it to your design system, and use it across every form in your app without modification.
How a field receives its context
There are two ways a field component receives its context, depending on how it is used:
Via hooks — when the component is registered in fieldMapping and rendered by the engine:
Via render prop — when the field is defined inline in config, the same props arrive as function arguments — no hook call needed:
Both approaches expose the same interface. The render prop is convenient for one-off fields. For fields used across multiple forms, a registered component is the better path.
See useField, useArrayField, and render prop for the full API of each approach.
A minimal field
Notice what this component does not do:
- It does not import anything from RHF
- It does not know what form it lives in
- It does not inspect validation rules
- It does not handle i18n —
labelanderrorMessageare already translated
Registering field components
Field components are registered once via fieldMapping in setupForm, then referenced by type name in any form config:
Passing extra props
Each field in config can pass additional props to its component via the props key, typed against the component's own prop interface:
BlueForm enforces at compile time that props matches the component's declared prop types — invalid props are caught before runtime.
Common patterns
Read-only state
A common pattern is to render a plain display value when readOnly is true:
Visibility guard
Respect visible at the top of the component:
Accessibility
Use id and ref from useField for proper label association and RHF's setFocus:

