(this page was created automatically. In case of formatting issues, please visit the official Wiki Page)

Input

Link to Figma: https://www.figma.com/design/yck1tcUXgdQ5aYX6iUAwrO/GE---Astronaut-Design-System?node-id=11628-199694&t=ftfrOGkPzlG2GaTo-1

Overview

• The Input component is a flexible form control for single-line text.
• It provides a customizable interface for capturing user input.
• The component supports validation, custom styling, and events.
• It is suited for short text entries such as names, email addresses, or references.

Specs

Tokens

Structure

• The component visually consists of a single-line text field, optionally with a label and icon.
• Supporting elements such as a character counter or data bindings may appear below or around the field.

(Configured in General Properties)

• displayName – Sets the display name of the component shown in the structure panel. For example, "Customer Email" allows for easy identification of the component's purpose in the application structure, making it easier for developers to locate and work with this specific input field.

(Configured in Non-Visual Properties)

• dataField – Defines the field name that will be used when submitting form data. For example, setting to "customerEmail" ensures the input value is submitted with this field name in the data object, making it clear what the data represents on the server side.
• controlsRequestType – Specifies how the field data is sent in HTTP requests: 'BODY', 'HEADER', or 'PATH'. For example, setting to "BODY" includes the input value in the request body, which is standard for most form submissions.

(Configured in Visibility)

• displayConditions – Defines conditions for displaying the component. This allows showing or hiding the input field based on complex rules involving other form values, user roles, or application state.

Styling

(Configured in Visual Properties)

• label - Sets the label text displayed above the input field.
• labelTranslations – Gives support for multiple languages. For example, {"en-US": "Email Address", "de-DE": "E-Mail-Adresse"} ensures proper localization of the field label based on the user's language settings.
• counterVisible – Determines whether a character counter is displayed below the input field.
• defaultValue – Sets the initial text value that will be used when the form is reset. For example, setting to "example@domain.com" would pre-populate the field with this value when a form is first loaded or reset.
• customIconName – Specifies a custom icon to display within the input field. For example, setting to "email" would show an envelope icon, providing a visual cue about the expected input type while enhancing the user interface.
• paddingClass – Configures spacing around the input component using CSS classes. For example, "p-4" adds medium padding on all sides of the component to improve visual spacing within its container.

Actions & Variants

(Configured in Events)

• events – Configures the events that the component can trigger and respond to:
• ON_VALUE_CHANGE – Triggered when the input value changes. Can be used to perform immediate actions based on user input, such as validating data, updating related fields, or triggering API calls.
• ON_INIT_BASED_ON_USER_VIEW – Triggered specifically when the component initializes in user view mode rather than edit mode.
• ON_INIT – Triggered when the input component is initialized. Can be used to perform setup operations like loading default values or setting initial states.
• ON_DESTROY – Triggered when the component is removed from the DOM. Useful for cleanup operations and releasing resources.

(Configured in Visual Properties)

• hidden – Controls whether the component is visible in the form. When set to true, the component remains in the form structure but is not displayed, which is useful for conditional input fields that should only appear in specific scenarios.
• readonly – Controls whether the text can be edited by users. When set to true, the input field displays the value but prevents changes, which is useful for display-only scenarios or when values are determined programmatically.

Validation

(Configured in Validation)

• validation – Configures validation rules for the input field. This object supports several validation types:
• required – When set to true, the field must contain a value before the form can be submitted.
• email – When set to true, validates that the input is a properly formatted email address.
• maxLength – Sets the maximum number of characters allowed in the input field.
• minLength – Sets the minimum number of characters required in the input field.
• pattern – Defines a regular expression pattern that the input must match to be valid.

Authorization

(Configured in Authorization)

• authorizationDisable – Specifies a policy set that determines when the component should be disabled based on user permissions. For example, setting to "readOnlyPolicy" will disable the input for users who don't have edit permissions according to the specified policy.
• visibilityPolicySetId – Determines the visibility of the component based on specified policy sets. For example, setting to "adminOnlyPolicy" restricts the input visibility to users with admin privileges.

Tests

(Configured in Testing Hooks)

• id – Specifies a unique identifier for the component used for programmatic access. For example, "customerEmailInput" enables targeted manipulation of this specific input field.
• dataTestId – Sets the testing hook ID for automated testing. For example, setting to "email-input" allows test scripts to reliably locate this component for automated testing of form functionality.
• enableAsHotspot – Enables the component as a guided tour hotspot. When enabled, the input field can be highlighted during onboarding or tutorial flows to explain its purpose to new users.
• guidedTourHotSpotTitle – Sets the title for the guided tour hotspot, supporting translations. For example, {"en-US": "Email Address Input", "de-DE": "E-Mail-Adresse Eingabe"} provides clear identification during guided tours.
• guidedTourHotSpotDescription – Sets the description for the guided tour hotspot, supporting translations. For example, {"en-US": "Enter your primary email address here", "de-DE": "Geben Sie hier Ihre primäre E-Mail-Adresse ein"} provides detailed instructions during guided tours.

Guidelines

Usage

• Use for single-line text capture; bind the value name and transport with dataField and controlsRequestType.
• Provide a clear, localized label using labelTranslations (sentence case).
  • Always provide clear and concise labels to help users understand input fields.
  • Use sentence-style capitalization for labels (capitalize only the first word unless it’s a proper noun).
• Offer help through tooltips, placeholder text, or helper text for clarity.
• Text inputs should allow free-form entry where appropriate.
• Pre-fill known values with defaultValue.
• Add an optional contextual cue with customIconName (supplemental to text).

Sizing & Layout

• Adjust outer spacing using paddingClass.
• When enforcing length limits, show a live character budget with counterVisible alongside maxLength/minLength.
• Hide the control when not applicable using hidden.

States & Feedback

• Switch to a read-only state with readonly for review scenarios.
• Configure validation via validation (required, email, maxLength, minLength, pattern); tie feedback timing to ON_VALUE_CHANGE (see Interactions).
• Preserve in-progress input with saveInLocalStorage.

Data-Driven / Conditional Behavior

• Drive runtime visibility from state using displayConditions; use disjoint expressions to avoid rapid show/hide oscillation.

Visibility & Authorization

• Hide for restricted audiences with visibilityPolicySetId or hidden.
• Keep the field visible but non-editable when awareness is important using authorizationDisable.

Content & Localization

• Localize end-user strings with labelTranslations.
• Enable onboarding aids with enableAsHotspot, guidedTourHotSpotTitle, and guidedTourHotSpotDescription.

Dos & Don’ts

Accessibility

• Provide localized, descriptive labels with labelTranslations for correct announcement.
• Prevent non-functional interaction by using readonly or authorizationDisable when edits are not allowed.
• Communicate constraints without color reliance using counterVisible, maxLength, minLength, and pattern/email within validation.
• Keep components discoverable and predictable with displayConditions and hidden.
• Prefer visibilityPolicySetId to fully hide restricted fields; use authorizationDisable to present read-only awareness when visibility is appropriate.
• Persist progress with saveInLocalStorage to reduce re-entry burden.