Removing the hash from generated classNames

[jamestowers]

I appreciate this kind of goes against the whole point of scoped CSS modules but is it possible?

I've tried to play around with the Webpack css-loader options.modules config but to no avail.

I'm interested in being able to use the generated classes outside of a JS environment - in server side templates - and the BEM style format you get in dev mode (with webpack) could work well, however obviously the hashes mean the classNames change on every build.
For context, we're running a React frontend but are exploring rendering some static pages on the server.

[mattcompiles]

I have a few of thoughts on this. Firstly I'd note that the classNames don't change on each build, they should be consistent between builds as long as you don't change the file name or re-order the styles. This is designed to ensure long-term caching works as well as possible.

On your use-case of using the classNames on the server, I'm assuming your server isn't running node? Because if it is you'd be better off importing the .css.ts files directly and using them just like you do in React. If you're using a different server setup then I can see why this isn't a simple issue.

If we removed hashes from the generated classes you'd be extremely likely to cause class collisions. Also the debug id feature (i.e. the thing that names the classes after your variable names) isn't a perfect system and probably shouldn't be relied on to make your production code work.

[jamestowers]

Thanks Matt,

That all makes sense, I hadn't noticed that the classname more often remain consistent, that's good to know.

Your assumption is correct, we're not running node on the server so that won't be an option.

The unreliable debug names feels like the last nail in this coffin, it was a far fetched idea but wanted to rule it out, thanks!

[phil-lgr]

As others have pointed out, sometimes you have to apply CSS vars and classes to non react or node applications.

In that case, you'll want to generate a final .css or multiples based on type safe vanilla's sprinkles and styles... and simply use the classes.

I think we should have an option to generate sprinkles and style classnames without hash (it has been already done for vars here #313) so why not surface an option in the plugins or directly with a function's option?

[phil-lgr]

Also requested here: #313 (comment)

[phil-lgr]

Similarly to what has been added to createGlobalThemeContract

We could have an option for defineProperties and style?

There are use cases where you will want to generate unique classnames without hashes (e.g. global theming) and export that for non-js environments

[RyderJKL]

It is still expected that the ability to remove hash will be supported, because in real business systems（for example, in the ui component library project）, where refactoring is often done, the directory structure and names of components are likely to change and the resulting hash will be disastrous for the real environment. This is because higher level components are likely to overwrite the old classname_hash.

[adamduncan]

If we removed hashes from the generated classes you'd be extremely likely to cause class collisions.

@mattcompiles Agree this certainly introduces that risk. Looking at the possibilities from the perspective of applications that aren't necessarily JS-/Node-based, I wonder whether there's some value in offering the ability to customise classnames.

As an example: One might be designing a component library, knowing components will mostly be used within React applications. However to afford reuse through static HTML sites and, say, Ruby or Django templating, components would benefit from a developer-friendly HTML classname API of some kind. Traditionally we'd leverage a convention (e.g. BEM) to mitigate some of the risk of class collisions, granted it's not bulletproof. E.g. As an example from Braid, we might hope for:

<div class="stack stack--align-center">
     <div class="stack__item">...</div>
     <div class="stack__item">...</div>
</div>

Does that seem like something that could be a consideration of vanilla-extract in future? You mention it being not such a simple issue for non-JS environments. Do you have any thoughts on how one might faciliate this reuse, while still reaping the authoring/type-safety benefits vanilla-extract brings?

Any input you have would be much appreciated. Cheers 👍

Edit: Related to #234 (reply in thread)

[mryechkin]

Has anyone found a solution or workaround for this? Currently investigating vanilla-extract to replace our existing styling solution in a design system component library we're building, and this is exactly the use case. Most consuming applications will be in React, however there are some cases where apps are simple HTML/CSS, and could benefit from consuming the same styles as the React components from the design system.

@jamestowers did you end up finding a solution for your use case?

[jamestowers]

Apologies for the later reply, I only just came back here to see if there was any news on the issue. I stopped looking for a solution but I'm still keen to find one. Passing a custom hashing function as in the linked discussion above could get us a long way there

[nmkae]

We're hoping to achieve a similar result where we are hoping to expose some utility sprinkles to support tailwind like class names on a simple div (without needing to import a function or drive it through another component) while also keeping the hashed class names for components (where class collision will be a concern). It's not clear if this is achievable in the current Vanilla Extract or if it will ever be.

[askoufis]

For future reference, fully custom hashes are now possible as of #1160.