Add terra-form-input component

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

[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!

[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