Terra-core: Add terra-form-input component

[dylanklohr]

Technical Design: terra-form-input

• Originally inspired by Ben Cai's preliminary tech-design.
• As this is an uplift, it's our goal to allow for all original functionality allowable by terra-form's input element. As such, this tech design is not meant to be an all-inclusive design over this new component's implementation. Rather, a set of new/notable features not currently implemented by the terra-form input element that I believe are worth calling out.

Summary:

Create a new package called terra-form-input to replace the Input component currently in terra-form.

Accessibility

Keyboard focus will be available for this form input.

React Props:

Old

See existing component's props table here.

New

| Props | Type | Default | Description |
| ----------- | ----- | --------- | --------------------------------------------------------- |
| disabled | bool | false | Whether the input is disabled |
| isInvalid | bool | false | Whether the input is invalid |
| onBlur | func | undefined | Function callback to trigger when this input loses focus. |
| onFocus | func | undefined | Function callback to trigger when this input gains focus. |

Themeable Styles:

• Background color
• Background image
• Border color
• Border radius
• Border style
• Border width
• Box Shadow
• Focus animation
  
  
  
  • Direction
  
  
  • Duration
  
  
• Font color
• Font size
• Font weight
• Opacity
• Padding

[ChaseSinclair]

On the original tech design, I noticed discussion around using disabled rather than isDisabled to stay consistent with other packages. Should we do the same for isInvalid?

[dylanklohr]

@ChaseSinclair I don't think so. When I looked deeper into the comments that you're referencing, I think the reason that disabled was used as opposed to isDisabled for form related components is because disabled is a first-class attribute of the underlying HTML <input> element that backs them under the hood.

Props in the form of is_ tend to be more of a terra convention, as they're used as a sort of flag that, when passed, they're meant to be indicative of a sort of change (being invalid, disabled, etc.). Were disabled not a first-class attribute of the HTML tag, and other new terra-form-X components not using it, I would actually probably opt to go for isDisabled as opposed to disabled, but given the reasons described above, I think we're okay to leave it as isInvalid personally, but I'm open to other opinions!

[samvaity]

I think it would be good to mention about the "Responsiveness" and "Accessibility" aspects of this component as it has some "Focus animation" and stuff going on with it?

[dylanklohr]

@samvaity I added a section about _Accesibility_. As the component doesn't have any non-trivial responsive behavior, I don't think it's necessary to add a _Responsiveness_ section

[dm123455]

Do we need to investigate handling of the truncation and the wrapping issue that occurs in IE and firefox?

[dm123455]

Do we need to account for helptext?

[dm123455]

The current input does not account for required fields, do we need it?

[dm123455]

Can we currently add place holder text? If not do we need it?

[dm123455]

Do we need to support error text with the red blob on top?

[jmsv6d]

@dm123455 Help text and error text is handled by the terra-form-field component.

[dylanklohr]

@dm123455 I emailed @bjankord and @neilpfeiffer about your first question regarding text truncation. Implementing placeholder text will be done as part of this story. Everything else you've mentioned above should be handled by the terra-form-field component.

[dylanklohr]

@dm123455 I talked with Brett and Neil this morning. Per Neil:

Terra will not doing any custom logic and follow default browser input behaviors for the immediate term unless otherwise noted.

[dm123455]

+1

[ChaseSinclair]

+1

[dylanklohr]

@bjankord, can I get your +1 on this?

[bjankord]

+1 on tech design.

[benbcai]

+1

[PaulSolDev]

JIRA created