Nodejs.dev: Inconsistent ways of adding CSS to components

Created on 11 Aug 2020  路  7Comments  路  Source: nodejs/nodejs.dev

Summary

Sorry for stepping on any toes. My intensions is only to make it easier contributing to this project 馃槃

When looking through the project I noticed that there is an inconsistent way of adding css to components. Some components have global styling, e.x src/components/Banner/Banner.scss and a few components uses emotion, some have .scss files in the component folder.

My suggestion is to use styled components or emotion for all components. I think it's easy to migrate and it will avoid global conflicts and overwritten styles.

Is it OK for someone to reorganize so we have it consistent through all components?

What do you think?

question

All 7 comments

From a performance point of view, I would go for CSS modules as it's the fastest and cheapest way to do CSS.

If we want better DX, I will look at glaze or goober. I do agree consistent is key here. Curios on what the rest thinks of which approach/library we'll be moving forward with.

Yep a lot has changed over time.
I think most of the components are using scss now.
I'm in favor of getting rid of emotion but I think thats the preference of the react ecosystem so 馃し

馃憢 I was about to open an issue entitled Use TailwindCSS instead of custom CSS but I saw this. I realize its a significant departure from what y'all have setup so far, but if there's interest I'd be open to spec-ing out that change.

The main benefit is that right now, we do have a lot of inconsistent styles in weird places, and a unifying behavior would be helpful. Tailwind is a well-used project that can be customized for our brand needs (colors, fonts, etc) but provides a ton of useful utilities so that we don't have to write a ton of custom CSS.

Personally, I don't think that any of the CSS module libraries are as friendly for external contributors as something more clear-cut and well documented as a CSS framework (Bootstrap, Tailwind, GitHub's Primer). The sheer velocity is important, and it takes a lot of guesswork out of actually writing components.

Thank you guys for the input! 馃憤

I agree with you @JasonEtco but I do think it's a shame to waste the current custom css we have been contributed with already. One idea as you said could be to use tailwind for the branding of global elements / typography / colors and keep the custom css for the components we already have.

Yes @benhalverson, good point. Most of the components are based on scss but I think it's easy to write sugar syntax rather than isolating styles for one element with a css-in-js library imo.

but I do think it's a shame to waste the current custom css we have been contributed with already. One idea as you said could be to use tailwind for the branding of global elements / typography / colors and keep the custom css for the components we already have. I think it makes easier to refactor this.

I wouldn't recommend mixing Tailwind with so much existing custom CSS, we just wouldn't get the benefits in any meaningful way.

I think its worth recognizing that code changes over time, and that's fine - we wouldn't have anything to talk about if there wasn't already so much work done! But I'd hesitate to use that as a reason not to change what we have now.

There are about 28 components (src/(components|containers/pages/templates)/*.tsx) - that's not that many pieces of code to update.

I don't disagree that that kind of refactor is best done iteratively though - we can certainly refactor a couple of components at a time where it makes sense to do so. But I wouldn't approach it with the long-term goal of having our existing custom CSS _and_ Tailwind.

To be clear, Tailwind (and any CSS framework) doesn't preclude custom CSS - it's just about the amount and where we put the majority of our styles.

Also important to consider community familiarity though. Tailwind is definitely an interesting approach (utility css), but it might not be friendly as our *primary approach to styling.

I'm definitely in favour of something like css-modules with scss if only because of it's broad appeal and accessibility.

(Of course, I'm glad to write in whatever formats we want to support, including Tailwind.)

Thanks for the input once again, I think #928 closes this one.

Would love to bring this discussion up again later if considering adding tailwind or css-in-js.

Was this page helpful?
0 / 5 - 0 ratings