Text Area

Sizes

<TextArea label="Small" size="sm" placeholder="Placeholder" />

<TextArea label="Medium" size="md" placeholder="Placeholder" />

<TextArea label="Large" size="lg" placeholder="Placeholder" />

Only three sizes: no xl/xxl, and no rounded variant. Figma defines neither for TextArea.

Label placement

<TextArea label="Adjacent label" labelType="adjacent" placeholder="Placeholder" />

<TextArea label="Inline label" labelType="inline" placeholder="Placeholder" />

<TextArea label="sm inline" size="sm" labelType="inline" />

Rows

<TextArea label="Bio" placeholder="Tell us about yourself…" />

<TextArea label="Details" rows={6} placeholder="More room to write…" />

Supported range is rows >= 2. At rows={1} the resize grabber overlaps the trailing icon/spinner cluster. Passing a lower value logs a dev-only warning rather than being clamped. Use TextInput for a genuinely single-line field.

Resize

<TextArea label="Notes" defaultValue="Drag the corner…" />

<TextArea label="Fixed size" resizable={false} />

Icons and character counter

<TextArea label="Search notes" leadingIcon={MaterialSearch} placeholder="Search…" />

<TextArea label="Bio" showCount maxLength={200} defaultValue="Plumber with 10 years' experience." />

Validation states

<TextArea label="Feedback" defaultValue="x" isInvalid errorMessage="Enter at least 10 characters." />

<TextArea label="Feedback" defaultValue="Great service, arrived on time." isValid />

<TextArea label="Feedback" defaultValue="Checking…" isLoading />

<TextArea label="Feedback" defaultValue="Locked" isDisabled />

When to use

Use TextArea for multi-line free-text entry: bio, feedback, notes, anything longer than a single line. It reuses the same shell as TextInput (label, description, helper/error, character counter) with a resizable multi-line body on top.

When not to use

• Single-line text: use TextInput instead. TextArea documents (and warns on) rows < 2 rather than supporting it. A single-line field is what TextInput is for.
• A fixed set of choices: use a select, radio group, or checkbox group instead of free text.

Both platforms

TextArea ships to @checkatrade/components-web and @checkatrade/components-native from the same Figma frame, at parity. See “Code” for the one real control-model difference between them.

Native is controlled-only: value and onChangeText are both required, with no defaultValue/uncontrolled path. This mirrors TextInput’s identical asymmetry and for the same reason: react-hook-form’s register() is uncontrolled on web but <Controller>-only on React Native, so an uncontrolled path on native would buy nothing. It isn’t a gap to close, it’s the two platforms’ own form-library idioms.

Props

TextArea shares the same FieldProps contract (label, description, helperText, errorMessage, isRequired, isDisabled, isInvalid, isValid) as TextInput. The control model and change handler differ by platform. See “Usage” above and “Platform status” below.

No rounded and no isClearable/onClear. Neither exists on this component on either platform (Figma defines no rounded variant for TextArea, and it has no clear button).

Import

Web

import { TextArea } from '@checkatrade/components-web';
import '@checkatrade/components-web/css';

The CSS import is required. It carries TextArea’s own type-scale and the resize-grabber inset alongside TextInput’s.

Native

import { TextArea } from '@checkatrade/components-native';

Basic usage

Controlled (both platforms):

// Web
const [bio, setBio] = useState('');
<TextArea label="Bio" value={bio} onChange={(e) => setBio(e.target.value)} rows={4} />;

// Native
const [bio, setBio] = useState('');
<TextArea label="Bio" value={bio} onChangeText={setBio} rows={4} />;

Uncontrolled (web only), the shape react-hook-form’s register() depends on:

const { register } = useForm();
<TextArea label="Bio" {...register('bio')} />;

Platform status

Web supports both controlled (value + onChange) and uncontrolled (defaultValue, no onChange required) usage. Native is controlled-only (value + onChangeText, both required). See “Usage” for why.

rows and Figma’s drawn height

rows defaults to 3. Figma’s frame is a fixed 120px, drawn at rest. Measured directly in a browser (2026-09-10), rows={3} renders:

The inline configuration’s height genuinely changes between rest and filled/focused: the label-shrink reflow is real, not just a label resizing in place. Open question for Oli: whether the rows-derived height above or Figma’s drawn 120px is the intended one. Not yet resolved.

Known limitations: native resize gesture unverified

The native drag-to-resize gesture has not been verified on a device or simulator. This is a gap in verification, not a claim that it works or doesn’t. The RN-web preview cannot substitute for this: reproducing a real touch/pan gesture is exactly what that surface fails to do. Still unverified: the gesture’s actual feel (native commits height on gesture end, not per frame, a deliberate divergence from web, since height is a layout property and animating one forces a Yoga pass every frame); touch priority between the resize grabber and the row’s own pressable area; the resize glyph’s appearance at 16px on a real screen; and whether Android’s numberOfLines (derived from rows) is a height hint or a hard line cap on a multiline field. If it caps, rows would silently limit how much text a user can type, a functional bug rather than a layout one.

Accessibility

Web

• aria-required / aria-invalid are set from isRequired / isInvalid (omitted, not set false, when not applicable).
• aria-describedby points at whichever of the description / helper / error slots actually renders.
• The resize grabber is aria-hidden and not focusable: a keyboard user cannot drag it, and the field is already resizable via the browser’s own zoom.
• labelType="inline" omits the visible required * marker and the description slot entirely, same as TextInput.

React Native

• accessibilityState/aria-invalid/aria-required mirror the web attributes.
• The resize grabber is hidden from assistive technology (accessibilityElementsHidden + importantForAccessibility).
• Hover state is mirrored from web via pointer events on react-native-web, a no-op on iOS/Android.

Both platforms

• Tone is never the only signal: the invalid state pairs a border colour change with visible copy (errorMessage).
• isLoading never disables the field: it stays fully editable while an async check runs.
• Control model: web supports both controlled and uncontrolled usage. Native is always controlled. Neither affects what assistive technology announces. See “Usage” above.
• Shared, upstream token issues: not TextArea-specific, and affecting TextInput identically: colorInputLabelValid and colorInputLabelDisabled are the same value (#4d4d4c), so a valid field’s label is visually indistinguishable from a disabled one’s.

No releases yet.