For Discussion: CSS classes option consistency about govuk-components HOT 3 CLOSED

My plan for this was to get an initial draft of the components in and then look at ensuring the API is consistent via something like form builder's traits and making them inherit from a single base class; then we can make these decisions in a single place and enforce uniformity.

I don't mind too much whether the classes argument takes a String, Array but I'm leaning towards having it accept both. Internally, combining arrays feels much cleaner than appending strings and there are patterns which work nicely in the form builder that we can use for inspiration.

When this is dealt with in a single place we can refactor and hone it until everyone's happy. I definitely think that standardising should be the next step once the components are implemented, although there's no reason we can't start that now.

from govuk-components.

I've made some progress on this. Now all the components inherit from GovukComponent::Base which deals with the classes arg. The same behaviour can be used throughout to set classes on the main element in the component. I'll add the same approach for custom HTML attributes shortly.

Since introducing slots, much of the 'subcomponent' functionality (i.e. tabs in a tab list) can be moved to its own class and called within the block (component.slot(:tab, title: 'Hello') { ... }), we can use the same approach here and add custom classes/attrs at the slot level.

This will give us all the flexibility of the official nunjucks macros but with a more Rails-like API.

from govuk-components.

I think this is now handled consistently throughout via the classes: keyword arg. Happy to have another look if it's not sufficient.

from govuk-components.