The text area is used to enter multiple lines of text. When empty, it can hold a placeholder similar to an input. You can define the height and width of the text area and also determine specific behavior when handling long texts.

• Implements the Text Area as a component as opposed to the Core implementation which uses a fd-form-control directive.
• Implements the FormFieldControl interface, thus can be used with in the FormField component.
• Internally adds character count message.
• Adds warning/error when maximum character count is exceeded.
• Adds automatic "growing" height.

Example of Core implementation:

<textarea fd-form-control placeholder="Field placeholder text" id="textarea-41"></textarea>

<fdp-textarea
[formControl]="<id of associated form-field>"
[size]="cozy|compact"
[readonly]="true|false"
[disabled]="true|false"
[autosize]="true"
[rows]="7"
[height]="200px|16rem"
[cols]="25"
>
</fdp-textarea>

The Input has the same features and functionality as the Textarea component in Fundamental NGX: Core. As such, the Platform Textarea component will be a wrapper around the Core Textarea component and will provide identical bindings as Textarea. Additionally, since this is an input element, it needs to implement the FormFieldControl as described in the FormGroup Layout or extend existing BaseInputComponent.

can be cozy or compact size of textarea form factors

whether this textarea is readonly.

whether this textarea is disabled.

Whether the textarea should grow dynamically based on the content.

Specifies the visible number of lines of text.

Height of the textarea. If both rows and height are specified, height overrides rows.

Specifies the visible width of a text area in characters.

The label for this form field.

The prompt text that is displayed when the input field is empty. Handled by form-field.

N/A

N/A

N/A

N/A

Form, Label

Note: Please note that label, labelIcon and isMandatory will be implemented/changed depending on how Label component is implemented.

Link to general support for i18n: Supporting internationalization in ngx/platform

Error messages will be supported as described in the Forms section in the above guidelines document.

Special Usecase: Yes

• A property from core's implementation showExceededText allows displaying a counter message showing remaining/exceeded characters when enabled. This message is coming from the library and therefore will follow the guidelines from the above doc. Since the message also includes the number of characters, the number can be supported by using DecimalPipe which can automatically translate numbers depending on the locale.

• fdp-textarea will be supported as:

<fdp-textarea
[formControl]="<id of associated form-field>"
i18n="@@contentTranslation
[size]="cozy|compact"
[autosize]="true"
[rows]="7"
[height]="200px|16rem"
[cols]="25"
>
..Some content here..
</fdp-textarea>

• All other properties like placeholder will come from the Form Field Control component so their i18n handling will be done according to that component.

Redesign Required: No

From Kavya-

1. How do we project the content of the textarea? Using <ng-content> does not seem to work properly.
2. If rows,cols and/or height is already specified, then using [growing]="true" should not have any affect right?
3. Counter implementation, growing functionality, cozy/compact usage all are missing in core currently. Should these features be implemented in core first since they are all Fiori3 requirements?
4. Similarly, help message styling and some other styling in accordance with Fiori3 are currently not reflecting in core either. Should these be directly implemented in fundamental-styles?
5. What is the need of labelIcon? It is not present in Fiori3 spec but in our FRD. Even if it is needed, will this be part of Label component of Textarea component?

Frank

• To your questions: 1: -> Why do want to project content into text area? its regular input control just like input 2: My comments later 3: Counter should not be part of the component, but its shoudl be implemented as part of the hint 4.5. my comments later

• You are mixing two things: Form Field elements that has certain common behavior and component itself.

• Just focus on the text area component and here dont reinvent the wheel look at the other implementation how you can improve it. e.g.: primeng , material

• The text area should focus on input nothign else:

  • Yes you can have type, but its should be more be size
  • No label, labelIcon, is Mandatory, state, showExceededText, ...=> all this will be part of the form.
  • Help message again will be part of the form, as part of the hint.
  • MaxLen - again you dont need this you build a form control and add Validator validator, There are outofbox angular directive for Max len.
  • It should not have columns, it will take up full width of its containers, just like other input controls. unless we support it for other inputs as well.
  • Rows|height - combine together to minRows,
  • Then when you have this growing, you shoudl specify maxRows how far it can go.
    • I like the binding called autosize like material have it.
  • **showExceededText **not sure what it is :
  • When you will have validation rule for the NgControll (NgModel / FormControllDirective), to alert when its larger than XXX chars, what is the point of shownig exeededText ?

Kevin

• I agree with most of Frank's points, but I'm wondering if we should keep the "state" property so that we're able to add the proper style the text area, when the field is invalid. Or perhaps we should have separate properties for "isValid", "disabled" and "readOnly"?

Kavya

1. Why do want to project content into text area? its regular input control just like input --> I saw an example of this in ngx/core so I assumed it would be needed, but I re-checked the code for that and they were taking that from the control itself, so yes this is not needed.
2. Counter should not be part of the component, but its shoudl be implemented as part of the hint --> I looked at MetaUI and am confused about the usage of hint, label and placeholder. Could you clarify what each of these mean? In material I observed that placeholder itself turns into label when focus enters the textarea, are you looking to achieve something similar? Fiori does not have that behavior: it has a separate label at top of textarea, placeholder to prompt text, and message at bottom to give meaningful feedback to user like success, error etc. Also the counter message like '3 characters exceeded' has a different style than the success/error message.
3. Will rename type to size
4. It should not have columns- Fiori3 spec says we should be having cols and rows and growing depends on these two properties as well.
5. Will try to incorporate autosize into this design.
6. Have updated meaning of showExceededText.
7. Kevin, I am also unsure of how to handle state because currently core is just adding readonly or disabled attributes directly instead of treating it like a state.
8. Regarding taking common properties like label, state, helpMessage, etc into Form, UX team and Manju have a different take on this and would like to discuss this further in the next call.