One often-overlooked aspect of CSS-in-JS is its "dark side"—the "JS" part. What does this mean? Essentially, when you're writing your styles within JavaScript, you expose yourself to the quirks and intricacies of JS itself.
The Issue Illustrated
Consider the following example:
You might notice that the styles defined in IBreakStyles aren't applied as expected. Digging into the element with your development tools reveals a complete absence of styles.
The Root Cause
The culprit is a stray closing curly bracket within the template literal:
const IBreakStyles = styled.p`
padding: ${({ $count }) => $count + "px"}}; /* <-- The offender */
color: red;
background-color: blue;
`;
What happens is that the CSS-in-JS library (in this case, styled-components) interprets the template literal in a specific way. This leads to parsing the CSS via JavaScript, and the stray curly bracket disrupts the intended behavior—likely closing some parent block in the JS logic.
The Silent Problem
The real issue is the absence of any alert mechanism: no errors are thrown, and no red squiggly lines appear in your editor to warn you. If you're fortunate, your editor's CSS-in-JS tooling might catch this, but that's not a guarantee.
A Thought to Ponder
Given these complexities, it's worth questioning if a separation of concerns—CSS in CSS files and JS in JS files—might not be a more foolproof approach, much like the "good old times."
Best regards,
Andi
CSS itself has some conceptual issues and limitations. If you use it the way it was initially intended, it works pretty straightforward. But some solutions try to overcome this limitations. If that means, that each element is marked with a classname behind the scenes, this will possibly bloat your files and cause more problems than it solves.
Any solution should be minimally invasive. If you just need some very conventional styling, it should allow to use the "good old solutions" and schould not affect your workflow.