TextInput collects short-form text like names, emails, or search queries. Use it for single-line values where the expected input is brief. Pair it with validation status to guide users through required or formatted fields.
ts
| Guidance | Practices |
|---|---|
| Do | Always provide a visible label so users know what the field is for. Only hide the label when surrounding context makes it obvious, like a search bar with a magnifying-glass icon. |
| Do | Use validation status with a message to explain what went wrong: "Email must include @" is better than just turning the border red. |
| Do | Size the input to match the expected content length so users can gauge how much to type: small for zip codes, medium for names, large for URLs. |
| Do | Add a clear button for search and filter inputs so users can quickly reset without selecting all text. |
| Don't | Don't use placeholder text as a replacement for a label; placeholders disappear on focus and are not reliably read by screen readers. |
| Don't | Don't use TextInput for multi-line content like comments or descriptions; use TextArea instead. |
| Don't | Don't mark every field as required; only flag mandatory fields so users are not overwhelmed by validation errors. |
Inputs with a leading icon that hints at the expected content. Use when the icon helps users identify the field faster, like a lock for passwords or an envelope for email.
Search input with a hidden label, start icon, and clear button. Use for toolbar and header search bars where the icon provides sufficient context.
Small, medium, and large inputs side by side. Use small in dense UIs like table filters, medium for most forms, and large for prominent single-field pages.
Error, warning, and success validation states with status messages. Use to show users what went wrong and how to fix it.
Text, password, and email types plus field-level features: tooltip, required, optional, description, disabled, and loading.