I've been a web developer for 10+ years now, mostly on the front-end, and I still find it difficult to name CSS classes, especially as a project grows. I've been using BEM for awhile and while this helps keep things scoped, there comes a time when you've used up a lot of the common component names and have to start getting more creative. So much so that I've resorted to keeping a (growing) gist of names.
Funnily enough, I don't seem to have this problem in naming JS components (for the most part). I work a lot with Vue and am thinking of trying out CSS Modules/scoped CSS in hopes it eliminates the need for CSS component names that BEM creates.
What are some strategies you use when naming things?
Top comments (12)
I'd say that naming things, regardless of the language, has to be one of the hardest things in computer science.
I'll break the pattern and I'd say that naming things isn't that hard at all. Yes, sometimes it may be hard to find the right name for a CSS class, for example, but I always figured it out like this:
Ask these 3 questions:
"What is this class for?"
"What is its purpose?"
"Why I made it?"
Now find out the core answer and voila, you made it!
Get rid of bem. Naming would be easier when using aria tags with css. Bem is overestimated and an overweight for both bundle and runtime.
Care to expand on this?
Sure.
I tend to use semantics and autotags for automation. Meaning I have maximum 3 nesting rules to define an element style and it does not break when I change the structure or doesn't break hard when replacing css framework.
Example css:
[settings-view] [role=submit-button] { width: 3rem; }
This replaces the bem part and overrides default rule set including framework values
Soon I will publish a post about this approach, meanwhile you can view the draft here eavichay.svbtle.com/preview/rfmQb8...
That's great Avichay 👍 be sure to let us know once the final version is published.
As you stated yourself, problem is not that common in Frontend because of Feature Modules approach and narower scope, but if you ever open complex backend codebase that deals with CQRS and other patterns or implement Custom Framework than big problems arise with and from naming.
Custom Frameworks tend to use generics and interfaces a lot and rather sooner than later Keywords such as Implementation, Mapper, Reader, Action, Model, Factory, Subscriber, ServiceChannel, Set, Result... (name it based on domain and technical usage) will become useless and not clear.
How to avoid it, define your domain (DDD) early on and stick with it. PERIOD.
Make everyone use agreed upon names and even if your names are long they will make sense and will be uniformed.
Discouss names for new classes with your team regularly and pick best options :)
aside: martinfowler.com/bliki/TwoHardThin...
haha. yep! I often think of that quote when I get stuck naming something
I like BEM for it's structure and still use it in combination with scoped CSS in Vue, but it works without scoping as well.
Think of your component as the block, then structure down from there and keep it as simple as possible. If you run into naming problems, your component might be getting too big.
Do you use a design system or build your app from scratch?
That’s pretty much how I work as well, except for the scoped css in Vue. My components stay small, but the issue becomes that I have the need for so many components I run out of names for the various types. I should note that I don’t really work on your standard Dashboard UI, those components are easier to name. I work on quite creatively driven mockups (think games) that the components aren’t immediately obvious as to what they are. To give insight my current project has over 100 unique Vue components (though a handful are HOCs).
App(s) are built from scratch.