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

Textarea

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

Overview

• The Dynamic Textarea component is a multi-line text input field.
• It is designed for entering and editing longer text content.
• It is suitable for comments, descriptions, feedback, or other detailed input.
• It provides configuration options for appearance, behavior, and validation rules.

Specs

Tokens

Structure

(Configured in General Properties)

• displayName – Sets the display name of the component shown in the structure panel. For example, "Customer Feedback" allows for easy identification of the textarea's purpose in the component structure.

(Configured in Visual Properties)

• value – Sets the initial text content displayed in the textarea. For example, pre-filling with "Please describe your experience…" provides users with context for what to enter.
• placeholder – Sets the placeholder text shown when the textarea is empty. For example, "Enter your detailed comments here…" provides guidance to users about what information is expected.
• saveInLocalStorage – Determines whether the textarea's content is preserved in local storage. When enabled, user input persists between page reloads or browser sessions, improving user experience for lengthy forms.
• defaultValue – Defines the initial value for the textarea that is used when the form is reset. For example, setting to an empty string ensures the field clears properly when the form is reset.

(Configured in Non-Visual Properties)

• dataField – Defines the field name used when submitting form data. For example, setting dataField to "customerFeedback" ensures the textarea value is submitted with this specific field name in the data object.
• controlsRequestType – Specifies how the field data is sent in HTTP requests: 'BODY', 'URL', or 'HEADERS'. For example, setting to "BODY" includes the field in the request body, which is standard for most form submissions.

Styling

(Configured in Visual Properties)

• labelTranslations – Sets the field label with support for multiple languages. For example, {"en-US": "Your Comments", "de-DE": "Ihre Kommentare"} ensures proper localization of the field label.
• rows – Determines the visible height of the textarea in number of text lines. For example, setting to "5" creates a textarea that shows five lines of text without scrolling, appropriate for medium-length responses.
• counterVisible – Controls whether a character counter is displayed below the textarea. When enabled, users can see how many characters they've typed, which is helpful when there are length limitations.

Actions & Variants

(Configured in Visual Properties)

• readonly – Controls whether the textarea content can be edited by users. When set to true, the content is displayed but cannot be modified, useful for displaying pre-filled information that shouldn't be changed.

(Configured in Event Actions)

• events – Configures the events that the component can trigger and respond to:
• ON_INIT – Triggered when the textarea component is initialized.
• ON_DESTROY – Triggered when the component is removed from the DOM.
• ON_VALUE_CHANGE – Triggered when the user modifies the content of the textarea.
• ON_INIT_BASED_ON_USER_VIEW – Triggered specifically when the component initializes in user view mode rather than edit mode.

Validation

(Configured in Validation Properties)

• validation – Configures validation rules for the textarea, including:
• required – When set to true, the field must contain a value before the form can be submitted.
• maxlength – Defines the maximum allowed character count. For example, setting to "500" limits responses to 500 characters.
• validated – Controls whether validation rules should be actively applied to user input.

Authorization

(Configured in Authorization Properties)

• visibilityPolicySetId – Determines the visibility of the component based on specified policy sets. For example, setting to "registeredUsersOnly" restricts the textarea to authenticated users only.

Tests

(Configured in Testing Hooks)

• dataTestId – Sets the testing hook ID for automated testing. For example, setting it to "customer-feedback-textarea" allows test scripts to reliably locate this component.

Guidelines

Usage

• Use for multi-line input such as comments or descriptions. Label the field clearly with labelTranslations; give optional guidance with placeholder.
• Match the expected response length by setting rows (e.g., short notes vs. longer feedback).
• When users may be interrupted, persist work-in-progress by enabling saveInLocalStorage.
• Present uneditable text (e.g., generated summaries) with readonly: true instead of a separate text component to keep visual consistency.
• Pre-fill only when it truly speeds up entry; otherwise prefer placeholder over hard value. If a reset should revert to a specific text, set defaultValue.
• Map the value to a backend field with dataField and choose how it’s sent via controlsRequestType (BODY, URL, HEADERS).

Sizing & Layout

• Set the control’s visible height using rows; adjust only in whole-line increments for predictability.

States & Feedback

• Indicate non-editable state using readonly; do not combine with required.

Data-Driven / Conditional Behavior

• Enforce maximum length with maxlength; pair with counterVisible so users can self-correct.
• Require input when business logic demands it by setting required: true; combine with validated to block submit.
• Persist drafts between sessions using saveInLocalStorage; clear by resetting to defaultValue.

Visibility & Authorization

• Show or hide the control based on user policies via visibilityPolicySetId.
• Identify the control in authoring tools without affecting end-user text using displayName.

Content & Localization

• Localize all user-facing copy with labelTranslations; keep it short and specific.
• Provide concise guidance in placeholder, localized per market; never rely on placeholder as the only label.
• Initialize user-visible defaults with value only when they are meaningful in all locales; otherwise rely on defaultValue + translations.

Dos & Don’ts

Accessibility

• Provide a persistent, localized label via labelTranslations; treat placeholder as supplementary.
  • Keep labels concise and unambiguous across locales.
• Communicate length limits textually using counterVisible alongside maxlength.
• Prevent impossible tasks by making non-editable fields readonly and by enforcing required only when validated is active.
• Keep content recoverable with saveInLocalStorage.
• Expose stable hooks for automated a11y checks with dataTestId.
• Avoid color-only cues; rely on text and validation states enabled via validated.