Normalize export strategy for component variants

[vpicone]

Why are PasswordInput and ControlledPasswordInput exposed as sub components of TextInput (TextInput.PasswordInput and TextInput.ControlledPasswordInput)?
They are exposed as exports from TextInput/index.js.
But not in the carbon-components-react/es/index.js.

I believe this is a vestigial pattern that you’ll see implemented in part across the library. (FilterableMultiselect I think?) Is the plan is to normalize/revert this strategy to make the variants more discoverable or to simply use props rather than duplicate, slightly altered components. For example, why PasswordInput and not <TextInput controlled type=“password”>

[guigueb]

👍
Thank you.
Although this does not impact the ability for them to work, it does impact the way clients interact/use Carbon.
It can lead to confusion and loss of functionality if abilities can not be found (I’ve never herd of FilterableMultiselect).
A single strategy would give Carbon a more polished feel.

[joshblack]

Let's totally roll this up into v11 👍

We can start figuring out the new exports today, as well, and start adding in deprecation warnings plus the new bindings.

[joshblack]

Tracking in: #8901