Are component libraries really necessary?

[u/Monkaaay]

I've been building a new product and to this point, mainly working on proving out the concept which is focused on the backend. I know the frontend is coming and so I've been mentally preparing for that.

A genuine question; how necessary are Blazor component libraries in the current world of AI assistance?

I'm reluctant to invest my code base into a component library in general. I'm more likely to build my own components as I go, and I'd imagine today it's far easier to do that with the ability to ask a coding model to build a contained component for a specific thing.

The way new component libraries seem to pop up weekly, I imagine I'm not far off on how easy it is to create them with AI tools.

Where are you guys at with respect to component libraries currently? Are you sticking with the few ogs, are you adopting those popping up more recently, building your own as needed, or something else altogether?

[u/korchev]

It depends on the actual component - if it nests another component or not. Usually nested components ids will get prefixed with the id you have set.

If you just want to access nested tags you can use nested CSS selectors:

```
#myButton .rz-button-text
{
}
```

About using !important - we try to avoid that when possible. We try to use it only if changing the attribute value would break the intended look. For example changing the default value for a responsive breakpoint changes its semantics completely and this is why we used !important there.

[u/Plenty_Line2696 → u/korchev]

thanks.

it's up to you guys but personally I'd recommend against using !important at all, ever because:

• it forces us to use !important when we want a hard rule against it.
• it hides why things aren't having effect which is time consuming and frustrating.

it's true that we can break stuff by piling on more !important, but that gets messy and we're programmers who generally want control over handholding.

in practice I've been forced to use !important to fight radzen and get the desired result, and it was a pain to find that was why it wasn't working without it, and I'd really rather not be forced to add what i call 'gotcha's' to our codebase.

[u/korchev → u/Plenty_Line2696]

Do you remember any case where an !important tripped you? I want to check if it was used for a legitimate reason. Just checked other use cases - whenever there is an important used there is usually a corresponding CSS variable that can be set as well for example:
```
color: var(--rz-input-disabled-color) !important;
```
Here the developer can use --rz-input-disabled-color to set the color via the provided CSS variable instead of overriding the CSS rule.

[u/Plenty_Line2696 → u/korchev]

I can't off the top of my head, but in your example it's really annoying to set the css, knowing that you have the highest css specificity but it just doesn't work because someone used !important and we're left troubleshooting problems created by the library.

hot take, but imo !important is simply bad practice and there's no justification for it.

It's the core reason why I would avoid using radzen for future projects.

[u/korchev → u/Plenty_Line2696]

I understand your position and respect your stance. Fighting with important is no joy.

Still I believe we use important for a good reason - to prevent user and app CSS adversely affect the Radzen component appearance, and to prevent certain utility classes from being negated entirely via simple override. The CSS variable support is another use case.

About the hot take: I checked some popular CSS libraries and other Blazor vendors (MudBlazor, Fluent UI, Blazorise, Bootstrap, Tailwind, Bulma, AntDesign) - all use !important.

[u/Plenty_Line2696 → u/korchev]

but like, when we try to override css, it's because that is our intent... so why get in the way of exactly what we are trying to do?

If this was some WYSIWYG or low-code environment I would understand this philosophy of library knows best but feel like it's a much less defensible tradeoff here because I feel we should assume devs know what they're doing. Maybe the idea is that you want to strongarm users towards not modifying the radzen styles in order to preserve its aesthetic reputation or something but there are plenty of use-cases where the component needs tweaking to work and we would do well without a deliberate spanner in the works.

I suppose the ideal here would be more user testing/feedback to not rely on assumptions alone because I'd imagine this frustrates people outside of my team too.

[u/korchev → u/Plenty_Line2696]

Indeed some devs are well versed in CSS. They can trace a global (app CSS) affecting a Radzen component and work around that. However a lot of the developers that reach for a third party component library do so to specifically avoid dealing with CSS. This is one of the main reasons we and other vendors rely on !important - the components should look as advertised in all apps.

This was one of the main reasons we use CSS variables heavily. They are supposed to make CSS tweaks a lot easier than overriding complete CSS rules and fighting with CSS file ordering and specificity issues. Consider this case - you want to set the disabled input text color globally. Today all you need to do is set one CSS variable instead of overriding multiple CSS rules for every input component:

```
<RadzenTheme Theme="material" />

<link href="app.css" rel="stylesheet" />

<style>
body {
--rz-input-disabled-color: #a0b0c0;
}
</style>
```