Fluid inputs: Evaluate indexing strategy for platform

[tay1orjones]

As part of adding the Fluid Inputs to the system #5416, something to consider is how we want these to be indexed into the platform.

Open questions:

• How/should the components be indexed? Experimental?
• How/should FluidForm be indexed?
• ...

[mattrosno]

You can view the assets currently indexed as part of the Carbon React library here: https://next.carbondesignsystem.com/libraries/carbon-react/latest/assets

The React library is indexed here: https://github.com/carbon-design-system/carbon/blob/main/packages/react/carbon.yml

If a new component needs indexed, and it's likely that other libraries will also offer that component, then it's best to define the component in the Styles package (https://github.com/carbon-design-system/carbon/blob/main/packages/styles/carbon.yml) and then also index it in the React library with the same id with additional information like status: experimental, and framework: react. Accordion is an example of indexing via inheritance that you can reference.

id matching and inheritance is what allows us to collapse assets when not filtering by framework (e.g. Accordion is available in React +4 other frameworks):

And then you can see other frameworks in the asset detail pages:

[mattrosno]

Also, I understand that not every exported component makes its way into the index: https://github.com/carbon-design-system/carbon/blob/main/packages/react/src/index.js

For example, we index Accordion, but not the subcomponent AccordionItem, because AccordionItem is documented via its parent Accordion.

You might have to make a similar decision - is FluidTextInput its own top-level component or is it documented through FluidForm?

[tw15egan]

I would consider FluidTextInput its own component, as well as the rest of the new Fluid components, for the sake of discoverability

[tay1orjones]

Related carbon-design-system/carbon-platform#1258

[sstrubberg]

is FluidTextInput its own top-level component or is it documented through FluidForm?

Yes, they will be their own top-level components.

How/should the components be indexed? Experimental?
How/should FluidForm be indexed?

As-is: Unstable_FluidTextInput
It should follow the same path that ProgressBar took.
To be: FluidTextInput

From a design side we might need to create little thumbnails. Check with Jeannie.

[tay1orjones]

We'll call this as complete - for now we're going to go with what we've got and index component variants like FluidTextInput as their own component.

If the platform changes strategies on how to surface variants, we can reassess at that point.