4 ms·
What is the convention? Beginning selectors in a file by the filename only? If I understand correctly, then I'd fallback on the linting. If the file is renamed
by emmacharp 4y ago
What is the convention? Beginning selectors in a file by the filename only? If I understand correctly, then I'd fallback on the linting.
If the file is renamed, then yes, you change the selectors. That's a simple operation. But I think the same goes for any JS framework where you'd create components. If you change "button" for "secondary-button" you'd have to change it in at least a couple of places I guess? Either way, you should limit these kind of operations to a minimum.
And what if I don't want to use VSCode? Maybe there are Tailwind plugins for every text editor...
But more importantly, that's quite easy to include your CSS files in the autocompletion of, for example, Sublime Text. I'd guess it's the same in VSCode. And again, simple linting should prevent much of these problems I think. You can easily lint contradictory rules in a ruleset. Stylelint would be perfect for that.
And if by mistake you have contradicting rules across rulesets, then a quick look at the devtools will tell you where the problem comes from. On a sidenote, the devtools become real difficult to use in a Tailwind-like paradigm.
- pcthrowaway 4y ago> If you change "button" for "secondary-button" you'd have to change it in at least a couple of places I guess? I'm not sure I understand this argument. If I rename a component and the file it's in, I get automatic import renames across the codebase without having to do anything myself. And if I didn't, I'd get errors trying to run the code (I'm not sure how you'd configure CSS to do the same thing with unmatched selectors, though I guess you probably could remove them from the output at least with postcss) > And what if I don't want to use VSCode? Maybe there are Tailwind plugins for every text editor... You do you, but according to the 2020 state of JS, 86% of JS devs were using VS Code, and 20% vim (which also has tailwind support): https://2020.stateofjs.com/en-US/other-tools/#text_editors https://2020.stateofjs.com/en-US/other-tools/#text_editors They removed the question so I don't know what current trends are, but Tailwind is at least supporting 90% of possible users with just those 2 (and I haven't looked into support for other IDEs) > On a sidenote, the devtools become real difficult to use in a Tailwind-like paradigm. I haven't found this to be the case at all, I'm not sure why Tailwind would make the devtools more difficult. If anything, it makes it easier since I typically only have to look at the CSS section for elements which have inherited styles
- emmacharp 4y agoA simple find and replace would do the same then for a CSS change. Again, that's not something that should happen often. As for support in text editors, you can still autocomplete any class you have in your CSS. And the CSS linting will give errors too if you have problems. And there are CLI programs for discovering unmatched CSS, which works pretty well in my experience. And the devtools suffer from all the added classes. It can slow down to a crawl depending on your machine. And you can't play as easily with the styles... If I disable a property in the cascade, all other items with this property will lose it. I would say it goes against the devtools grain. But I guess it depends on your usage.