New feature: custom prefixes for class names

[mzygmunt]

Something like this:

const gridStyle: string = style({
    color: "red"
}, {prefix: "grid"});

Then the style name in the HTML code would look like this:

<div class="grid_f1d5jrmm">
...
</div>

It will be useful in some cases, because the source of the page will be more readable.

[basarat]

Don't use classNames to do debugging. Two ways:

• I add data-comment on the dom node e.g. <div data-comment="myDiv" className={generatedClass}/>.
• To comment className you can use '-comment':'name' as - prefixed names don't collide with any future CSS spec that might introduce comment. You will see it in the generated CSS that helps with quick debugging. Personally I don't like to leave this in as it wouldn't pass a CSS validator.

Hope that helps 🌹

[rcchen]

So I have a different use case for this, that is not debugging related.

Let's say for example that I have an app with two components from independent packages that both use Typestyle. Is there some way to ensure that there aren't class name collisions between two components, which were styled with different instances of Typestyle?

My first instinct was to add a prefix somehow, or (potentially more awesomely) there's a guarantee that any permutation of styles maps to a unique class name.

Curious to hear thoughts on this.

[basarat]

which were styled with different instances of Typestyle

Have typestyle as a peerDependency :rose:

[notoriousb1t]

The underlying hashing function for generating classnames is djb2. It uses the property names and values of the style to create a unique class name. While the chances of class name collisions in a single instance of TypeStyle is very very small, that algorithm is not guaranteed to be collision-free. This is a trade-off between speed and exactness.

If two styles were to collide for some reason, adding a custom property or using the $debugName property would resolve the issue. A custom property would change the resulting hash, and $debugName is a prefix to the hashname, so that would resolve it as well.

Adding a second TypeStyle instance does not increase the chance of a collision.

[rcchen]

OK sounds like we'll be ok then, thanks for the guidance @basarat @notoriousb1t 😄