Let’s talk about CSS and React!

One thing is that it can make your React and HTML & CSS development experience so much smoother if you define your CSS and styles directly in the React component (.tsx) files. Many people may say it’s heretical to ‘mess up’ React components with embedding CSS in there. But the reality is that it makes you quite a bit more productive when you don’t have the constant headache from having to switch between React components and style sheets. The firmly rooted ideology of keeping them separate, I believe, is based on the assumption that other people, such as UX designers, would be responsible for updating the styles whereas the ‘nerds’ would take care of the code part of the components.

In reality, I haven’t seen a single project where this would be the case. It was always the developer that would do the both. It turns out, the styles typically are quite deeply entangled with the DOM structure, which is defined by the component. How you organize your React components deeply affects the structure of the accompanied CSS files. Therefore it generally does not make sense for UX designers to go into such detail that they directly edit CSS files.

As writing the final CSS for the React components goes tightly hand-in-hand with creating the actual components, it feels quite obvious to place every component’s style in the same file with the component.

There are quite some nice React libaries that make your styles in React code look really neat, such as Styled Components.

Some Practices With Styled Components

Styled Compoents is a great way to smoothlessly embed CSS into your code and also improve readability by giving some semantic meaning to your elements.

Let’s have a look at a sample implementation of a styled component:

const Div = styled.Div({
    backgroundColor: 'black',
    display: 'flex',
    flexDirection: 'row',
}); 

const Input = styled.input({
    color: 'white',
    border: 'none'
});

export const FormField = (props: { 
    label: string;
    value: string;
}): ReactNode => (
    <Div>
        <Label>{props.label}<Label>
        <Input type={'text'} value={props.value} />
    </Div>
);

I’ve been writing styled components this way since about half a year now on a bad-ass customer project with extremely high quality requirements. I can tell you, writing React code with styled components this way makes you feel like having a grip like it never was in the past when the styles were placed in separate files. I have used separate plain CSS files and pre-compiled CSS files in the past, such as Sass, PostCSS etc. and I have been doing it a lot - since decades! The guideline by the Wise of the Internet always was that embedding styles directly in the JavaScript code is a bad practice. But once you take your first step to the ‘dark side’ and start embedding styles in the code in the way described above, there’s no coming back!

About Bootstrap and Other ‘CSS Frameworks’

There are many CSS frameworks, such as Bootstrap, Materialize etc. I think such CSS frameworks can be a good starting point for unexperienced style tweakers to get something look proper without a lot of hassle. However, the problem is that while Bootstrap provides a proper looking default layout, the reality is that the customer usually comes up with a design that deviates from the standard Bootstrap style. Then you start entering problems because you will need code your own styles on top of the default Bootstrap styles. You end up partially rewriting and covering up underlying Bootstrap styles and that isn’t a beautiful thing by definition. It’s sort of a hack that you have to start ‘fixing’ the default sauce by mixing in your own flavors. There will be maintainability problems in the long term. If the customer has their own unique design for the UI, you would be better off writing your vanilla styles from scratch and get rid of the underlying ‘framework’ mess that does not quite fit into what you are really doing.

How About Tailwind CSS?

I can’t control myself from losing my temper at all when someone starts insisting that we should use Tailwind. Ah just kidding, actually I can! Namely, I have learned to control my temper over this particular matter. I have practiced a retarded sheep-like loving smile in front of the mirror especially for these special occasions that someone (usually someone with less-than-ideal amount of CSS experience) says ‘Tailwind’.

I think Tailwind CSS is one of the dumbest things on the block. Tailwind CSS has the idea that you make your CSS ‘atomic’ by having predefined set of ‘atomic’ CSS classes. Now that is, to be honest, a very stupid idea. Namely, you don’t need these ‘atomic’ classes because the CSS natively also provides these things called ‘properties’ that are already really atomic by their nature. You just need to ‘read the friendly manual’ to understand them. But it definitely pays off. Now what if the CSS properties are ‘too atomic’ for your taste? That’s why you can write CSS classes. Their purpose is to group CSS properties into entities that you can use separately or combine in your code as you wish. You will end up in a quite neat and maintainable structure if you do it with care and love. With Tailwind, on the other hand, you will end up writing insanely long class strings containing long lists of classes, for example:

<div class="flex items-center justify-between p-4 bg-blue-500 hover:bg-blue-600 text-white font-bold border border-blue-700 rounded-lg shadow-lg transition-all duration-300 transform hover:scale-105 hover:shadow-xl focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-opacity-50 focus:bg-blue-700 active:bg-blue-800 active:shadow-none active:transform-none sm:w-full md:w-3/4 lg:w-1/2 xl:w-1/3 2xl:w-1/4 h-auto text-sm sm:text-base md:text-lg lg:text-xl xl:text-2xl uppercase tracking-wide leading-relaxed">
    Horrific Tailwind Example
</div>

At the end of the day, you will want to simplify those cryptic class hieroglyphes somehow - likely defining a class to describe a group of classes. Which begs the question, what’s the point in all that hassle? Why not keep it plain and simple, be patient enough to really take the effort to understand the basic CSS and use the default mechanism that it offers. Not having that patience is a bad excuse for screwing up your code with Tailwind!

Getting Rid of CSS Classes Alltogether

If we want good code then we don’t want to add more CSS classes to our code and we definitely do not want to mess up our code with Tailwind insanity. What we actually might want to do is the opposite of adding more classes - let’s get rid of them alltogether. Yes, a class-free world is possible! Namely, if you start embedding your styles into your React code, a whole new world of opportunities opens up to you. You can actually use the TypeScript (or JavaScript) programming language’s native features to organize your CSS properties - which is way more powerful than any CSS pre-processor (such as Sass etc.) ever. Writing React components becomes more intuiitive because you use the same code logic that you use for components also to manage your CSS properties.

I’ll be back to this exciting topic very soon. Cheers!

I’ll be back. Cheers!