feat: implement getComponentSlotClassName utility for dynamic class name generation

[dmytrokirpa]

Previous Behavior

Previously, we generated classes from the component state using the pattern .fui${Component}--${stateValue}. For example, .fuiButton--primary for a button with the state { appearance: "primary" }, or .fuiButton--small for { size: 'small' }. These classes were mapped manually.

New Behavior

This PR introduces the utility getComponentSlotClassName, which maps component state to CSS classes using a new structure: .fui${Component}--${stateName}-${stateValue} or .fui${Component}--${stateName} if the value is a truthy boolean. For instance, a state of { appearance: "primary", size: 'small' } will result in the class names fuiButton--appearance-primary fuiButton--size-small.

Related Issue(s)

• Fixes #

[github-actions]

📊 Bundle size report

✅ No changes found

[github-actions]

Pull request demo site: URL

[layershifter]

Considering that the RFC (#35464) was not merged, please don't put any related utils into stable packages.

[dmytrokirpa]

Considering that the RFC (#35464) was not merged, please don't put any related utils into stable packages.

That's true, and the RFC hasn't been merged yet. However, since it isn't impacting anyone and there's no alternative way to validate the approach and gather real data from partner codebases, I believe we can proceed with checking this in.

I can add a note indicating the utils is not meant for public use, or rename it to be getComponentSlotClassName__experimental/getComponentSlotClassName__unstable if you think that would be helpful.

[layershifter]

@dmytrokirpa is there a reason why these utils cannot be shipped in a preview package?

[dmytrokirpa]

@dmytrokirpa is there a reason why these utils cannot be shipped in a preview package?

For the headless style hooks, they really need to stay in the component packages - otherwise, the bundler's .headless.js resolution trick won’t work. As for the getComponentSlotClassName util, we could totally ship it as a preview package, but I’m not sure there’s much upside since we’d still have to add it as a dependency for the component packages. Unless I’m missing something here!

@layershifter If you have any ideas or suggestions on how we can improve this, I’m all ears.

[dmytrokirpa]

Merged this PR to the headless-components branch instead of master to not block progress, and once the RFC is approved/merged we'll merge it back to master.