CSS class names generated by Emotion: more descriptive and unique per UI component


In Grafana’s UI there are numerous CSS class names that, for example, look like: .css-4x8o14, .css-1wqk4q5-input-input, .css-utyk8k-input-wrapper or .css-mh1vgn-button. This seems to be coming as a result of using Emotion library.

However it causes an immense amount of pain for developers trying to support own custom CSS theme for Grafana.

Because whenever Grafana source code goes through a change in any of the React components’ CSS styles, Emotion library would re-generate a new CSS class name for it. So, let’s say, we in our project have just made our own custom style overriding the styles from .css-4x8o14. If in the next version upgrade of Grafana there were any changes in the React component that was originally using styles from .css-4x8o14, the class name .css-4x8o14 would now be gone, as Emotion library generates a new hashed class name for it. Hence, our custom style for .css-4x8o14 would no longer take any effect. We would have to manually track what is the new class name and add support for it once again.

Would there be a chance if you could investigate this and in future provide better CSS class naming conventions in Grafana for cases using Emotion library?

It would be great if CSS class names were fully descriptive and unique per UI component they correspond to. If Emotion library doesn’t allow setting a fully custom CSS class name instead of a dynamically generated hashed one (e.g. having something like ‘.data-source-core-button’ instead of .css-1e35lzp), it probably allows setting a custom ending at least. For example, currently in toolbar some of the buttons use these kinds of CSS class names: .css-1t4b87h-toolbar-button (most of the buttons in the topmost toolbar), .css-cdo4z7-toolbar-button (‘Apply’ button in the toolbar, which has a different look from the other buttons). In case there is a change coming, only the hashed prefix would get re-generated while the ‘-toolbar-button’ ending would stay the same (which solves the problem as we can use a CSS selector [class$="toolbar-button"] to tackle it). However, a big deal of CSS class names in Grafana either don’t have any non-hashed ending at all, or it’s not unique per component. E.g. this case with -toolbar-button button, there are 2 different types of buttons in the toolbar that look differently, and the trick with the CSS selector can’t be applied because of that. It would be a great help if the CSS class name suffixes reflect on that - having separate names like e.g. .css-cdo4z7-general-toolbar-button and .css-cdo4z7-form-action-toolbar-button.

Would be very grateful for your help!

Best regards,


hymm – emotion css names should be considered ephemeral and there is zero expectations that they will be stable from one build to the next. In the past the global css names made is super easy (and super common) for plugins to have all kinds of unintended side effects on other parts of the system.

With emotion, you can set the theme variables programatically

Yes but we are not proposing not using Emotion altogether, or a complete shift to global css names. It would be enough if the css class names produced by Emotion had a stable prefix or suffix, along with the random hash. There should be a way for that, for example like here:

That would solve the problem mentioned in the post, if that prefix/suffix is defined uniquely per React component.

Would this be something Grafana team could look into? We would be really grateful!

Hi @sabinaf,

It might be difficult to get this noticed rn, because the core squads are busy getting ready to release Grafana 8 in June.

I have seen that we respond positively to feature requests that gain upvotes and traction within the community. It seems like this could really help, but I’m personally not equipped to say whether or not it can be done.

I’d suggest making a feature request and seeing if it can gain momentum.

1 Like

Hi @mattabrams,

Thank you for the suggestion, will create a feature request then!

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.