Platform: Textarea Component Technical Design

Textarea Component

Summary

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.

Design:

<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"
[showExceededText]="true"
>
</fdp-textarea>

Usage with Forms:

<fdp-form-field #ff9 
[id]="'Detailed description'" 
[placeholder]="'Start entering detailed description'" 
hint="This is the inline help that comes as a tooltip" 
zone="zLeft" 
required="true" 
[validators]="textareaValidator">
   <fdp-textarea [formControl]="ff9.formControl" [size]="'cozy'"></fdp-textarea>
</fdp-form-field>

Property Bindings in fdp-textarea

size: string

can be cozy or compact size of textarea form factors

readonly: boolean

whether this textarea is readonly.

disabled: boolean

whether this textarea is disabled.

autosize: boolean

Whether the textarea should grow dynamically based on the content.

rows: string

Specifies the visible number of lines of text.

height: string

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

cols: string

Specifies the visible width of a text area in characters.

showExceededText: boolean

Turns on the counter, which shows the remaining or exceeded number of characters.

Property Bindings in fdp-form-field

id: string

The label for this form field.

hint: string

The text part of inline help that appears as a tooltip. Handled by form-field.

placeholder: string

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

validators: ValidatorsFn[]

array of validations that will be applied to this textarea. eg in the above html snippet, [validators]="textareaValidator", textareaValidator will be something like this:

this.textareaValidator = [
      Validators.maxLength(5), //allows max length of 5 characters
      Validators.pattern('[a-zA-Z ]*')   //allows only text as input
    ];

Removed:

required: boolean

Whether the textarea is required(asterisk) to be filled. Handled by form-field.

state: string

Can be one of disabled|warning|valid|invalid|readonly. The helpMessage will take the appropriate state's color.

helpMessage: string

A short message to provide feedback to users.

maxLength: string

The maximum number of characters that can be entered in this textarea.

---

Event Bindings

N/A

---

Two-Way Bindings

N/A

---

Content Projection

N/A

---

Interfaces

N/A

---

Related Modules

Form, Label

Additional Notes

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

Questions

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?

---

Comments

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.