Input

In context

Purpose

Input collects one value from the user — a name, an amount, a note. Its job is to make entry fast and reassuring for someone who finds typing a chore: a large field, a visible label, an obvious focus state, and errors that explain rather than scold.

Anatomy

• Label — always present, always above the field. A placeholder is a hint, never a label.
• Field — the tap area; at least 48dp tall, with a subtle grey border.
• Prefix / suffix — an optional fixed affix inside the field, e.g. a Ks currency marker.
• Helper or error text — quiet guidance, or a clear recovery message when something's wrong.

States

A field sits on a subtle grey hairline — a control needs a defined edge to read as tappable. When it's active, the stroke darkens to a clear neutral grey — a neutral cue, never brand colour, and no shadow. On error the border turns red and says what to do — colour alone isn't a message.

Code

import { Input } from '@daytwo/components'

<Input
label="Sale amount"
keyboardType="numeric"
value={amount}
onChangeText={setAmount}
helperText="Use the number pad — no need to type currency."
/>

When to use

• Collecting a value that genuinely needs typing — a name, an amount, a short note.
• Capturing money — set keyboardType="numeric" and add a Ks prefix so the user types digits only.

When NOT to use

• For a choice among a few known options — use chips or a picker. Typing is the most expensive interaction we ask of the user.
• For a yes/no setting — use a switch.
• As the only path to capture — offer lower-effort routes too (a receipt photo, a repeat-last-sale shortcut).

The correct scenario

Logging a cash sale: a Customer name field and a numeric Sale amount field with a Ks prefix. The labels stay visible while typing, the number pad is one tap away, and the user never has to type the currency or guess what a field is for.

Anti-patterns

Edge cases

Tokens used