Refactor god class 'IClassProvider'

[njannink]

The IClassProvider is an anti-pattern god class. It contains the class building for all components and extensions so on each enhancement on new extension you will need to update this interface and all implementing providers making maintaining it a nightmare and finding logic also complicated.

Would be better to use a decorator pattern like

interface ICssProvider<TComponent>()
{
   IEnumerable<string> GetStyles();
   IEnumerable<string> GetClasses();
}

Then you can implement where needed a CssProvider for specific frameworks and components. Also theming + defaults logic you could then move to these component providers making the components cleaner and easier to maintain.

I know this is a big refactoring maybe for a 3.0 release, but would certainly improve the API and maintainability on the long run.

[stsrki]

This is intentional. I tried many different approaches, including what you proposed, but then it would be even harder to maintain. Because instead of only one central logic, you now need to keep many files for each component. And they would be hard to keep track of. That's why we want a centralized place.

[njannink]

Maybe it can be a combination. So common classes and logic you keep in the classprovider and component specific logic you put in specific css providers.

public class BarDropdownToggleCssProvider( ThemeProvider theme, IClassProvider classProvider ) : ICssProvider<BarDropdownToggle>
{
    public IEnumerable<string> GetStyles( BarDropdownToggle target )
    {
        yield break;
    }

    public IEnumerable<string> GetClasses( BarDropdownToggle target )
    {
        if (target.ParentBarDropdownState.Mode == BarMode.VerticalInline)
            yield return "b-dropdown-toggle-inline";
        if (target.IsDisabled)
            yield return classProvider.Disabled();
        if ( !target.ToggleIconVisible.GetValueOrDefault( theme.Theme.DropdownOptions.ToggleIconVisible ?? true) )
            yield return "b-bar-toggle-icon-hidden";
    }
}