Implement success state for OnyxFormElement

[larsrickert]

Depends on

• Implement OnyxInput #189

Why?

There are cases where it is necessary to communicate an explicit success state for an FormElement:

• To highlight the validity of important inputs (E.g., a password input on sign-up)
• To show validity after an asynchronous validation (E.g. Chosen username is available).
• To show the successful execution of an action related to the input (E.g., Value copied to the clipboard)

The (validation) valid state independent of the success state:

• the success state is set explicitly and not the implicit result of validation
• the validation error state has higher priority than the success
• the success state does not change or affect the validation
• for now only support for inputs (text, select) and not for textarea

Design

https://www.figma.com/design/EBi98T51T9fGfjrYYfsulg/onyx---Archive?node-id=3427-73120&t=WFV3kII28sKTTZft-4

Acceptance criteria

• A new type FormMessage is created
• message, successMessage, errorMessage all use the new type
  • • Message precedence from highest to lowest:
      1. errorMessage
      2. html native validation error message
      3. successMessage
      4. message
• when successMessage is shown, a green checkmark symbol is shown on the right -> Follow up Implement green checkmark on OnyxInput #2143
• All existing components that use the OnyxFormElement are extended to support the new API
• Follow-up from Fix small layout jump on invalid OnyxInput / OnyxFormElement #1731: Refactor to only show onyx-form-element__footer when any message is shown: Right now the gap is from the parent is applied even when no message is visible

Definition of Done

• covered by component tests
• screenshot tests are updated
• follow-up tickets were created if necessary
• updated version + documentation is deployed
• Storybook can show the feature
• Set task to In Approval

Review

• Input
• Textarea
• approved by designer @jannick-ux
• approved by dev @JoCa96

Implementation details

Consider that success might be shown without message, but error should never be shown without message. Also, do we still need a message for a11y reasons?

/**
  * If it's just a string it acts as `FormErrorMessage.shortMessage`
  */
export type FormErrorMessage = string | {
  /**
   * A short error message preview that is shown permanently beneath the input field
   */
  shortMessage: string;
  /**
   * An extended message that is shown temporarily after hovering over the message tooltip.
   */
  longMessage?: string;
};

/**
  * Message precedence from highest to lowest:
  * 1. `errorMessage`
  * 2. html native validaiton error message
  * 3. `successMessage`
  * 4. `message`
  */
export type OnyxFormElementProps = {
  // Refactor the messages to take the same format:
  successMessage?: FormErrorMessage;
  errorMessage?: FormErrorMessage;
  message?: FormErrorMessage;
}

[mj-hof]

@jannick-ux Open questions:

• What's the use case behind that success/valid state?
• Do we need the "copy"-button? Misleading user interactive?
• What about text area, selection controls - do they have a valid/success state as well?

[jannick-ux]

• The success state can be used for forms that need to be validated (e.g. the user needs to fill out his personal data and the system checks, if the username could be validated). It is a completely optional thing for concepting, although it could be really handy in some usecases. So I created it as an optional addition.
• The copy icon is optional as well. It gives the opportunity to copy the content with one single click. I got the request of this features from several sources. Why do you think it is misleading?
• Selection controls don't have text area because the "success indicator" validates an input, but not a binary choise.
  Text areas have no success state as well, because of their purpose. They aren't used for inputs that can be correct or incorrect (like the OnyxInput does). The have the purpose to insert continuous text (that can be formatted). Continuous text cannot be valid or invalid.

[JoCa96]

Story was split and "Copy action" is moved to #1887