What's the use of customRootClass?

[kotAPI]

What is customRootClass and why is it such a commonly found prop in the library?

[kotAPI]

A critical aspect of a headless UI library is that it should be unstyled, allowing developers to apply their custom class names and style components using their own CSS.

In libraries like Ant Design or Material-UI, you typically have to import a massive CSS file into your project. This often leads to a "specificity war," where customizing components to meet the exact requirements of your product designer becomes a frustrating, time-consuming process. You may find yourself overriding one class after another just to achieve a pixel-perfect design. This approach is not only hard to maintain but also prone to bugs and can become a nightmare in large codebases, where engineers are constantly adding and overriding custom implementations. The potential side effects of these changes are unpredictable and difficult to control.

Rad UI takes a different approach. We provide an optional CSS file that developers can import if they want to quickly build their application without worrying about extensive customization. Many users prefer libraries that look good out of the box, but how do we cater to both groups—those who want default styles and those who need full customization—without compromising on developer experience? The solution lies in our customRootClass feature.

With customRootClass, developers can effectively detach a component from the default Rad UI stylesheet. For instance, consider the default structure of our Accordion component:

.rad-ui-accordion {
    .rad-ui-accordion-item {
        .rad-ui-trigger {
            // default styles
        }
    }
}

If you set customRootClass = "acme", the component's structure transforms as follows, completely detaching it from the default styles:

.acme-accordion {
    .acme-accordion-item {
        .acme-trigger {
            // your custom styles
        }
    }
}

This feature allows developers to easily bypass the default styles and apply their custom classes, avoiding specificity wars and giving them the flexibility to build pixel-perfect components without the overhead of overriding existing styles. It strikes a balance between providing a great out-of-the-box experience and supporting complete customization.

[kotAPI]

Feel free to add your thoughts and suggestions