feat(FluidTextInput): create unstable__FluidTextInput component

[tw15egan]

Refs #11785
Closes #11994

Utilizes existing FluidForm component to create a new unstable__FluidTextInput variant.

Changelog

New

• unstable__FluidTextInput component, mimics the current usage of the Fluid TextInput example, but requires less work for end-users to configure

To Do

• Write tests (Use RTL for testing in FluidTextInput/__tests__/FluidTextInput-test.js #11994) (will be completed after this is merged in, so we can utilize build(react): add a script that scaffolds out RTL tests #11941)

Testing / Reviewing

Go to the `FluidTextInput story and ensure all variants are to spec and render correctly.

[netlify]

✅ Deploy Preview for carbon-components-react ready!

Name	Link
🔨 Latest commit	5026350
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/6310fa76cd55500008553cfc
😎 Deploy Preview	https://deploy-preview-11971--carbon-components-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	ea5c163
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/62fcf3eb5ae0a1000944aadc
😎 Deploy Preview	https://deploy-preview-11971--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	5026350
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/6310fa766a03380008a085d8
😎 Deploy Preview	https://deploy-preview-11971--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[tay1orjones]

This looks good so far! A few thoughts below.

Previously we had said the reasons for breaking something out a new component would be if it not only modifies styles but also behavior or accessibility. What behavior would be different between TextInput and FluidTextInput? Could we write separate tests to cover FluidTextInput specific behavior or would TextInput tests cover it?

Overall, I do think the conflict of props between fluid vs. non-fluid support these being their own component.

Having all fluid inputs as their own components has a few advantages I can think of too:

• All fluid input stories will be co-located in the storybook left panel
• Each fluid input will have their own "folder" and set of stories that will be snapshotted and tracked with VRT/Percy.
• Makes it more clear for consumers the API difference between Fluid vs non-fluid

Do you think the mismatch between component name vs style file is a problem? In order to use FluidTextInput the user has to ensure text-input.scss styles are included. Conversely, I don’t think we’d want to duplicate all the styles in text-input.scss to a new fluid-text-input.scss, so the existing situation is probably fine.

What should we do with the existing isFluid props out there? Deprecate them with a note to use the new component could be a good first step.

[tw15egan]

Previously we had said the reasons for breaking something out a new component would be if it not only modifies styles but also behavior or accessibility. What behavior would be different between TextInput and FluidTextInput?

I agree with this in most circumstances, but since this seems to be a bundle of new components and not just a one-off variant, I tend to lean towards bunching them together. You've accurately summarized my thoughts on the advantages of creating a new component, and to me, they outweigh the negatives. This should also be coordinated with Design to ensure they are on the same page and that they are planning to bundle Fluid components together, rather than have them co-exist inside the TextInput or other form element design files.

Do you think the mismatch between component name vs style file is a problem? In order to use FluidTextInput the user has to ensure text-input.scss styles are included. Conversely, I don’t think we’d want to duplicate all the styles in text-input.scss to a new fluid-text-input.scss, so the existing situation is probably fine.

I hadn't thought of that; that could definitely be seen as confusing. We could make a new fluid-text-input.scss that imports text-input.scss and just contains the fluid specific styles, sort of how we do MultiSelect and the other ListBox components.

What should we do with the existing isFluid props out there? Deprecate them with a note to use the new component could be a good first step.

I think that makes sense. Once this is merged (or included in this PR), we can mark the isFluid prop as deprecated, noting that the new variant is available as a standalone component.

[tay1orjones]

We could make a new fluid-text-input.scss that imports text-input.scss and just contains the fluid specific styles, sort of how we do MultiSelect and the other ListBox components.

@tw15egan Nice! That sounds like a good idea. Could include it here, or do it in a separate PR. I added it as an item on #11785

I also made #12003 for the isFluid deprecation

[aagonzales]

All the styles look good to me!! 🎉

[tw15egan]

@tay1orjones you may want to check it over again (the last two commits). In #12003 I realized it was wrapping each TextInput in its own form wrapper. To avoid this, I removed the FluidForm wrapper in FluidTextInput and referenced the isFluid context directly. We still need that context value due to the way the elements are rendered in TextInput. We may need to use that in other fluid form elements that we create, but I'm not sure yet.

Instead of scoping styles to form.cds--form-fluid they are scoped one level lower and I've added a new class .cds--text-input--fluid. I've ported all relevant styles to the new fluid-text-input.scss file but left the old styles in place until V12.

[aagonzales]

All the styles still look good 👍

[tay1orjones]

I think we want these to be experimental from the start

Suggested change

	export FluidTextInput from './components/FluidTextInput';
	export FluidTextInput as unstable__FluidTextInput from './components/FluidTextInput';

[tay1orjones]

Suggested change

	title: 'Components/FluidTextInput',
	title: 'Experimental/unstable__FluidTextInput',

From a quick search, it looks like some story files include the unstable__ prefix, and others don't. Either way is good with me. FluidForm does not.