Addon support for TextInput

[rishson]

Specification

This widget builds on the existing textInput widget and allow the user to specify an 'addon'.

Below is an example of addons from bootstrap. It shows leading, trailing and multiple addons:

Features

• You can have both leading and trailing addons on a single textInput.
• You can specify text, icon, or text + icon for either leading or trailing addons.
• You can include form widgets such as a checkbox or radioCheckbox in an addon.

Value-add of the widget (e.g. why use rather than just use VDom directly)
builds on the existing textInput and offers visual prompts to aid completion, e.g. type of values accepted

List of callback funcs that can be passed in props (if any)
none

Mouse/keyboard interactions (if any)
possibility to show different tooltips when hovering over leading and trailing addons

Mandatory/valid/empty/wait states (if any)
none

Is the widget controlled/uncontrolled
as per textInput

List of any icons needed
any icon in font-awesome that we ship should be usable as either a leading or trailing icon.

Design input required
Need to consider how we style an invalid or mandatory input that has addons.
Need to consider using addons and putting a textInput into a wait state.
Need to consider how we style addons if the textInput is disabled.

Any other considerations:
Initial support will not include changing the icon based on validity of the textInput.
With an input of type search, will Addon provide all we need to effectively offer a Search widget?

Questions

Need to consider if the icons should be spoken as they are included for informative purposes.
Need to consider what happens if long text is specified for an addon. Do we ellid the text, always show, ..

Acceptance criteria

When I specify an addon with text and an invalid icon, then I expect the text to be rendered without the icon.
When I specify an addon with unicode text, then I expect it to render correctly (including adjusting for height of non-latin chars).

[bitpshr]

This should be taken care of as part of the next round of components for beta4.

After discussions with the team over the past few weeks, it sounds like the best approach for this component would be to add an additional property (or two) to TextInput to handle leading and trailing add-on strings. Because there can be multiple add-on strings on each end of an input, each property may make the most sense as an array of strings. Alternatively, if the desire is to keep TextInput as clean as possible, a new component that uses a TextInput internally could be created that supports properties specific to add-ons.

Adding functionality (vs. modifying functionality) in this manner doesn't lend itself well to direct extension of TextInput. Specifically, because TextInput is highly accessible form control, its render method is inevitably large. While the generation of some of the necessary attributes and listeners could be offloaded to helper methods, extension is less than ideal to add functionality to a component with such little vdom with so many attributes.

Action items:

• Leave this ticket open to track the creation of this component for beta4