WIP composable primer styles

[BlakeWilliams]

This introduces a new module, Primer::Styleable which adds methods to a
component that generate primer based class names.

[BlakeWilliams]

Should probably prefix these methods with d_?

[joelhawksley]

Or, could we do d(:table_cell)?

[BlakeWilliams]

Or, could we do d(:table_cell)?

We totally could. I went with methods for this first attempt at an implementation instead of arguments since it will immediately raise an error instead of requiring us to validate the arguments. Thoughts?

[manuelpuyol]

should we have VALID_DIRECTIONS?

[nuthinking]

Personally I think that View Components should treat Primer classes as second class citizens (in the future these perhaps shouldn't be allowed?). Hence I'm actually more in favour of using them (for now) explicitly (i.e.: classes: "d-inline-block etc...") or maybe even primer_classes: "...". Finding new ways to express them could make it hard to get rid off them.

[BlakeWilliams]

Personally I think that View Components should treat Primer classes as second class citizens (in the future these perhaps shouldn't be allowed?). Hence I'm actually more in favour of using them (for now) explicitly (i.e.: classes: "d-inline-block etc...") or maybe even primer_classes: "...". Finding new ways to express them could make it hard to get rid off them.

I think that's an interesting thought, and brings up a really good point, how much do we want to couple these components to Primer through methods? Additionally, how coupled do we want to allow people to opt-in to components being coupled to primer?

The original goal of this approach is to help remove the need to use **kwargs in so many components. The thought behind this approach was to build a module that you can include that gives you explicit methods that generate primer classes. I think one advantage here is that the DSL could be replaced/updated to support any CSS framework's classes. So if we update primer classes upstream we could easily update these methods to support the new version's CSS classes.

I'd also be 👍 on removing **kwargs in favor of something like:

def initialize(tag_name:, primer_classes:)

Assuming that would be a 1-to-1 replacement.

[nuthinking]

So if we update primer classes upstream we could easily update these methods to support the new version's CSS classes.

Is this really a realistic scenario?

[BlakeWilliams]

Is this really a realistic scenario?

I believe so, it looks like one of the last times we had a breaking CSS name change was in December 2019 here, primer/css#966 so there is some precedent.

[BlakeWilliams]

Closing for now, since we want to stick with a more React-like API