Is a package like classnames “overengineered”? I stated on Twitter that a package called classnames felt overengineered to me. I based myself on the npm page where this code example is given:
var btnClass = classNames('btn', this.props.className, {'btn-pressed': this.state.isPressed,'btn-over': !this.state.isPressed && this.state.isHovered});
The first reason I felt this was overengineered was because this kind of code actually belongs in CSS:
.btn:hover {/* Styles */}.btn:active { /* Styles */ }.btn-pressed { /* Used as .active I presume */ }
I understand why giving something a class conditionally might be handy, but do you really want people to figure out that a button should have a class of btn-overwhen the state is not pressed but hovered?
And then have that match up to another logic on the CSS side?
Bramus and Sebastian rebutted that it’s actually a very handy utility. So I am sure there are situations I am not aware of where it might be handy.
At the moment I feel like it’s only invented because of a deeper problem: trying to write CSS in Javascript.
1 Comment
There are plenty of CSS-in-JS packages, primarily in the React ecosystem. This isn’t one of them. What this one achieves is dynamically applying classes to an element. The example may be bad but the use cases are there: conditionally hiding an element without having to alter the DOM structure, highlighting bad form input, etc. There’s a tendency to make that sort of thing more declarative now using JSX, but there’s nothing wrong with an imperative change to the DOM.