So `<div class="gallery">` is loose coupling, because the styling is not coupled directly into the element. You can completely switch the gallery design, by switching (or overriding, or modifying) the external stylesheet.
as for tailwild, I just can't bare its wide-ness - too many className attribute string going over 150~300 char widths, with some ternary operators mixed on top...
(seems vanilla-extract / ete have better DX, with occasional inlining for immediate deadlines)
But the problem is that you need to make sure that a given css change is going to affect only a specific set of component. So you need to check all components. Since it will be too time consuming, you will probably skip this step and hope for the best (and do some QA to check that nothing is obviously broken).
- read from webpack's output
- read from css-in-js: emotion / vanilla-extract / etc
What kind of fragile markup and problematic CSS global rules are you worrying about?
I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case.
As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.
You want to preserve the theme an consistency of the UI, but adapt its functionality. For this type of changes the semantic version is problematic.
You don't like global styles? Don't use global styles, period.
Even without adopting Nue and staying on React, CRA and Next comes out with CSS Modules out of the box. Angular and Vue have their own equivalent.
Isn’t it much more meaningful to create a <gallery> component (it can be done through a template-engine, react, whatever, that’s another point).
I mean, sure, we could just program with void pointers everywhere, but is it really a good idea?
If I modify the HTML structure, the component specification changes and CSS obviously needs to be updated.
Loose coupling vs tight coupling has an established meaning ≈ “if a change to module X causes a failure in module Y, then we say X and Y are tightly coupled.” This has some “knock-on” effects that you are trying to gesture at, like, “If two modules are tightly coupled then because of that tight coupling we usually have to coordinate deployments between them both.” And then you're like “I can ship new CSS without having to coordinate a deployment of HTML, that must be loose coupling then!”
But this is a sloppy way to use the language, because in the one case you have one module, and in the other case you have two: there is no coupling in the Tailwind case because there is nothing to be coupled because it all ships as one module, then you construct a more modular approach, one with two modules in fact, and these modules are (depending on how you squint at it given that we are doing decorative programming and there are no explicit errors) in fact “tightly coupled”—the semantic HTML essentially provides a customized API which the CSS uses by hooking into; this is a common form of tight coupling in microservice deployments for example.[1]
So you are actually looking at, one module plus a static asset that defines a common language, vs. two modules that are tightly coupled, and declaring that the two modules are “more loosely coupled” and this is somewhat of a nonsense thing to say. Like I get what you were going for, I didn't write this as a top level complaint because I understand what you meant, but here in the thicket of comments I see that you are not communicating well with your interlocutor because of this sloppiness and language, you might want to pivot?
[1] This point about microservices is likely to outrage a random passerby, look I am sure that your microservices use RPCs against HTTP APIs in a way that doesn't cause you much grief in having to update multiple modules in one commit (if monorepo) or stage “topics” (Gerrit’s term) where you carefully have to merge 2 or 3 pull requests to different repositories all at the same time (if multi-repo). But even though your microservices are loosely coupled, I have worked on very similar architectures where we did have to stage topics and if you didn't then changes to service X would break service Y, “We’ll ship a new value for this enum, that requires changing the common schema repo, which requires updating every microservice that looks at that enum so that it doesn't have a deserialization failure ‘this is not an allowed value for that enum’ when the new values start rolling out, the ones that actually switch() or if() on that enum need to be updated to do the right thing, oh, I missed one because it relies on the contract that if enum == x then fieldA is set but if enum == y or z then fieldB is set but now when enum == q neither fieldA nor fieldB is set...” and I am happy that you haven't had these problems but yeah, some microservices are tightly coupled by this definition.
vs here:
(the gallery component)