Terra-core: Uplift Field Component for OCS

[emilyrohrbough]

Issue Description

Uplift Field component.

Issue Type

• [ ] New Feature
• [x] Enhancement
• [ ] Bug
• [ ] Other
  #

[emilyrohrbough]

Field Tech Design

Summary:

The first phase of the uplift will be to maintain existing functionality.

Field can be broken into the following pieces:

• Label Group: displays the Label & when applicable, the required asterisk. [See Notes/Questions # 2.A]
• Control Group: displays the control and placeholder text
• Error Text
• Helper Text

Below list the needed themeable variables for each piece.

Responsiveness:

• Label, error and helper text will always wrap if the available width is exceeded.
• Work needs to be done to determine the feasibility on determining label group width, control width and relational widths. [See Notes/Questions # 1]

Accessibility

None to consider in the first phase of the uplift.

Needed React Props:

• inError prop [bool] weather or not the field is in error. If in error, show the error icon and error text.
• hideRequired prop [bool] weather or not the required asterisk should be displayed.
• showOptional prop: [bool] appends '(Optional)' to the end of the label. [See Notes/Questions # 2.C]
• errorIcon prop: [Icon] the error icon to display when a required field was fails validation.[See Notes/Questions # 2.B]

Expected Future Props:

• labelPosition prop: [string ('above', 'beside')] weather the label should be above or to the left of the control. [See Notes/Questions # 3]
• errorIconMessage prop: [node] the information to be displayed in the error icon tooltip when the error icon is present. [Will need additional design input.]

Themeable Styles

Field Themeable Styles:

• Padding Bottom
• Border color
• Border style
• Border image source / linear gradient / border image slice [See Notes/Questions # 4]

- Focused

• Border
• Box shadow

-Error & Required

• Border color

- Error & Required & Focused

• Border
• Box shadow

Label Group Themeable Styles:

• Padding bottom
• Line height
• Label font size
• Label font weight
• Label font color
• Required asterisk color
• Error icon color

Placeholder Themeable Styles:

• Font size
• Font weight
• Font color

Error Text Themeable Styles:

• Font size
• Font weight
• Font color
• Padding top

Helper Text Themeable Styles:

• Font size
• Font weight
• Font color
• Padding top

Notes / Questions

1. Spike needed on determining Label Group Width, Control Width and Relational Width. This directly ties with # 2.

2. The label Group's width must be large enough to display label, required asterisk and error icon at all times.
   A. Assuming asterisk dimensions flex on font-size, can you calculate the expected asterisk/icons width to apply to the entire div's width?
   B. Need to also consider space for when the error icon is displayed.
   C. Need to also consider space for when the appended text '(optional)' is display.

3. Current designs indicate label should be positioned above or to the left.
   A. Should label placement be bidi?

4. The use of Border image only appears to be supported by >= IE 11.0 (https://www.w3schools.com/cssref/css3_pr_border-image.asp)

Needs More Design Input

1. What are the width considerations regarding error and helper text?
2. Do we always want to display helper text or only when field is in focus?

[mjhenkes]

For question # 3, Lets Just offer above label positioning. Left position can be a later enhancement.

[mjhenkes]

We also may need to spike on the field selection animation that some themes are requesting.

[JakeLaCombe]

I can assist with that spike. I'm actually responsible for textarea this iteration.

[emilyrohrbough]

Been looking in more depth & the themeable aspects of field can be narrowed to the label-group, help text and error text. The placeholder and focus styling should be implemented by the control passed into the field as a child.

[emilyrohrbough]

Updating inError prop to isInvalid.

[mjhenkes]

+1

[bjankord]

+1 on tech design. There is an issue I logged related to field but I would not include it within the scope of this tech design as it is a non-passive change, though I did want to raise visibility that the issue exists and if we have non-passive changes we need to make as a part of this tech design, we already have 1 queued up.

[emilyrohrbough]

The behavior/inclusion of the isInvalid prop will make likely make non-passive according to @mjhenkes's comment here.

[emilyrohrbough]

Do we want to call this new package terra-field or terra-form-field?

[kschuste]

I would go with terra-form-field for specificity

[StephenEsser]

My vote is for the shortened terra-field. If this component will be the first to be broken out into a package it will set the standard. I think terra-form-textarea, terra-form-select, and terra-form-checkbox are overly verbose.

I saw that there was a warroom topic over the naming convention, was there a consensus on how they should be named?

These examples feel descriptive to me
terra-select
terra-textarea
terra-field

[StephenEsser]

For the labelPosition prop, is this just the difference between inline and block labels?

[mjhenkes]

@StephenEsser We agreed to append form to the labels of these components to continue to group them together with forms. We agree that terra-form-field would be cumbersome to type however we expect people to alias the components:
import field from 'terra-form-field';

[bjankord]

This has been released in terra-form-field 1.0.0

[PaulSolDev]

Orion JIRA created