readable class names

[jeremy-coleman]

what do you think about changing the hash to readable class names? for ex , instead of .sajfsfdaflalsfkja {color: red}, just use .colorRed {color:red}. Because all the styles are de-duped, this doesn't present any problems, and could also let users inspect discrepancies in their styleguides by just comparing a list of all the generated names

[CraigCav]

Thanks for the suggestion Jeremy!

I'm definitely open to meaningful/readable class names, although I'm not sure sure what conventions we would need to put in place to support it. Simple styles like color: red would work well, but probably not so well for hex colors, rgb(a) colors or hsl(a). Any thoughts on how we would handle those?

It would be cool if we could use abbreviated naming patterns inspired by other atomic CSS libs like tailwind.

[jeremy-coleman]

Id just keep them as is, as in colorRgb2550301 or whatever it comes out to after removing parens and commas. I think as long as you can tell what classes are effecting the element, mission accomplished

[giuseppeg]

It would be cool if you'd prepend the final class name with the original rule identifiers eg.

const link = css`
  color: red;
`

<div className={styles(link)} />

 ↓ ↓ ↓ 

<div class="link_a3wf color_vr3w">

Optionally prepend link_a3wf with the file name eg. Button_link_a3wf. I do this in dev in style-sheet to add source maps https://twitter.com/giuseppegurgone/status/1138119300068384768

[jeremy-coleman]

You can't do that for atomic rules, that defeats the whole purpose ;p . Atomic meaning that a rule key:value always only has 1 value and is always only registered once. The point is that the hashing is completely unnecessary for atomic rules, because they're inherently unique already. Also, unless the hash algorithm is deterministic and content unique, the order in which you register rules matters, making it pretty much impossible to optimize.

[giuseppeg]

The link_a3wf would be an empty rule just for debugging purposes. As for the atomic css classes, I agree that they are already unique but the value can be quite long which is why in my example I hashed it. The hashing function used in this library is deterministic. Insertion order in this context is not relevant.

[jeremy-coleman]

I just feel like its possible to make this beautifully simple. Also insertion order is relevant, even when pre-building, because of incremental compilation, but that shouldn't be actionable here lol