Written by Leonardo Maldonado✏️
CSS hasn’t always been an important part of web development. Before CSS was popular, many companies had ugly and inaccessible sites. Throughout the years the web has evolved, new frameworks were created, JavaScript consolidated as the main programming language for the web, developers were improving their frontend skills. Now, we have a lot of concepts for styling the web.
A lot of developers will remember the time when we used to do a lot of work to work with HTML and CSS. We had to create a separate .css file, link our new CSS file by using the link tag in our HTML document, and after this, we had our CSS styling working fine.
Styling our applications using CSS was sometimes a challenging job. We didn’t have a lot of new CSS features and browsers didn’t support a lot of new features. Do you imagine yourself having to use float: left and float: right to position elements?
That was pretty hard for some developers to understand at first, but a lot of things changed in the last few years and CSS styling is one of them. React is the most used JavaScript library for modern applications, and has brought with it a lot of new ideas and concepts to style our applications.
CSS styling in React
In the React ecosystem, we have a lot of different libraries for different purposes, and in the styling part of the frontend it’s the same, we have a lot of libraries and concepts to style our React applications. Here is one of the most used ways to style a React application:
CSS modules
A few years back, a lot of developers were using and advocating for the use of the CSS modules styling in the React community. With CSS Modules, you have all your class names and animations scoped locally by default, it works pretty similarly to the old way of styling in HTML documents. Here is an example:
.container {
width: 400px;
height: 400px;
background-color: blue;
}
A module is just a simple .css file, and it renders into the HTML using a dynamic CSS class name, the whole idea of this concept is to avoid name collisions or affecting the styles of other components in our applications:
.container_4xks92k2kl {
width: 400px;
height: 400px;
background-color: blue;
}
CSS-in-JS
The trending way to style React applications today is CSS-in-JS, we have a lot of famous libraries to do that such as styled-components, Emotion, Radium, etc. A thing that you should know about CSS-in-JS is that CSS-in-JS is not a specific library, it’s a concept that tries to solve the problem of styling in React applications.
Since React is all about components, why not use it to style our elements as well? That’s the idea that CSS-in-JS introduced to us, instead of passing a lot of class names attributes to our elements, let’s create specific styled-components and benefit from the idea of componentization that React introduced to us:
import styled from "styled-components";
const Button = styled.button`
width: 200px;
height: 40px;
background-color: green;
border-radius: 6px;
`;
Now, let’s talk about the most used way to style React applications, why this concept is not a very good idea for your applications, and why you shouldn’t use it.
Inline styling in React
Inline styling is one of the most common ways of styling React applications, a lot of developers start to use this concept when they’re starting a new application because it’s very easy to understand at first and you can achieve the same final result that you would achieve in other concepts like CSS-in-JS and CSS modules. One of the reasons why the inline styling is very famous and used is because when a new developer is starting to learn React, they probably will start with the inline styling concept.
We can use the inline styling in plain HTML documents as well. If you want to test it, just create a plain HTML document, and create a style attribute in the element that you want to style. In plain HTML documents, this style attribute receives a string, and inside that string, we can pass our CSS properties, like this:
<button style="width: 200px; height: 50px;">My Button</button>
In a plain HTML document, the type that the style attribute expects is a string, a little bit different from React.
Inline styling in React is pretty simple, all you need to do is create an object, and inside that object, you pass the CSS properties that you want:
const styles = {
width: 200,
height: 50,
backgroundColor: 'red'
};
The properties in our styles object must be camelCase style, this is something related to the JavaScript language, we cannot have kebab-case because it does not work with the syntax rule.
Now, we can pass this styles object to our element. Each element in React has a style attribute, similar to each HTML document, but in this case, the style attributes expect an object. This is how we can use inline styling in React.
import React from "react";
const styles = {
width: 200,
height: 50,
backgroundColor: 'red'
};
const Button = () => (
<button style={styles}>My Button</button
)
When you’re using inline styling in React, you don’t need to pass a unit to a property in CSS, you can pass just a number and React automatically appends px to your numeric inline style property.
But, we have some problems with the inline styling in React, especially if you’re working in a big application and have a lot of reused components. Even if you’re not working in a big application yet you’ll eventually start to feel some of the disadvantages of inline styling in this post.
What’s the problem with inline styling?
We know that inline styling works really well when we’re starting a new application, and we can apply it everywhere we want in our code. But if this concept works fine, why should we stop using it?
The inline styling concept might not help you to build the best React components in your app. If you’re planning to build a very performant, scalable, and rich application inline styling is not the right option for you.
CSS features
One of the main reasons that inline styling is not a good choice for your application is because it does not support (or it has really poor support) for CSS features.
Every application nowadays might have to end up using some selectors such as :hover, :active, :focused, etc. How can we achieve this same behavior with inline styling? Well, it’s trickier and sometimes you might end up with a lot of unnecessary code just to achieve a simple :hover in your component.
Using a CSS-in-JS library, you can achieve it very easily like this:
const StyledButton = styled.button`
width: 200px;
height: 50px;
background-color: red;
&:hover {
background-color: blue;
}
`;
const App = () => {
return (
<StyledButton backgroundColor="green">
My Button
</StyledButton>
)
};
If you’re not planning to use CSS-in-JS to do that you’ll end up having to write a lot of code, maybe even use the state to simulate the hover in the element. This is one of the most painful points about inline styling and this is a major reason why you should consider moving away from inline styling in your applications.
Props
Sometimes when we’re building our React components, we want to achieve a nice level of component reusability, sometimes we’ll end up in some situations where we’ll need to change a specific property of our CSS element. Let’s imagine that we have a button, and the default backgroundColor of this button is red:
const Button = () => {
return (
<button
style={{
width: 200,
height: 50,
backgroundColor: "red"
}}>
My Button
</button>
);
};
But, what if I want to use the same button, but in this case, I wanted to change the backgroundColor to green? On a daily basis, we face these situations, and the inline styling here cannot help us create a good component.
We might have to end up using JavaScript ternary statements, which it’s not a good idea because it will leave our code heavier, hard to understand, and grow the component size.
const Button = ({ green }) => {
return (
<button
style={{
width: 200,
height: 50,
backgroundColor: green ? "green" : "red"
}}>
My Button
</button>
);
};
We can agree that this code it’s not looking good. We have to use a JavaScript ternary statement to change only one property of the button style, imagine if we had a complex component with 20 changeable properties? It would become a mess very quickly.
Otherwise, in CSS-in-JS libraries, all we have to do is pass property to our style, and it’ll change depending on the value of the prop, like this:
const StyledButton = styled.button`
width: 200px;
height: 50px;
background-color: ${({ backgroundColor }) => backgroundColor};
`;
const App = () => {
return (
<StyledButton backgroundColor="green">
My Button
</StyledButton>
)
};
Media queries
It’s a default behavior nowadays that applications support mobile devices, so you’ll have a lot of media queries in your application.
But, if you’re using inline styling, you can’t use media queries because it does not support it. Remember, you’re using a plain JavaScript object to pass to your element, how could you use media queries?
You can use it by creating some custom function to get the actual width window size, like this:
const minStyles = {
width: 200,
height: 50,
backgroundColor: "red"
};
const maxStyles = {
width: 300,
height: 50,
backgroundColor: "blue"
};
const App = () => {
const renderStyles = () => {
if (window.innerWidth <= 800) {
return minStyles;
}
return maxStyles;
};
return <button style={renderStyles()}>My Button</button>;
};
But imagine it in the long-term, imagine if you need to support five different media queries, what your code would look like? It would be really messy and not easy to understand at all. And also, you would have to create a lot of styles objects just to handle all media queries.
Scalability
Imagine an app that has to reach millions of users every day. You’ll end up in an application with dozens of components, and the inline styling might slow you and your coworkers down a little bit to create new components or maintain those that already exist.
If you’re still with some inline styling components in your application, and if they’re working fine, for now, you can stick with this concept for a while. The intention here is to show you why your application will not be very performant and scalable in the long-term.
One of the jobs of developers is to try to find the most performant solution that won’t take a lot of time to implement and also help build a strong, resilient application in the long-term.
Conclusion
In this article, we learned about some ways to style React applications, we learned more about the inline styling concept in React, and why we shouldn’t be using this concept if we’re planning to have a scalable and productive application.
Full visibility into production React apps
Debugging React applications can be difficult, especially when users experience issues that are difficult to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.
LogRocket is like a DVR for web apps, recording literally everything that happens on your React app. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app's performance, reporting with metrics like client CPU load, client memory usage, and more.
The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.
Modernize how you debug your React apps — start monitoring for free.
The post Why you shouldn’t use inline styling in production React apps appeared first on LogRocket Blog.
Top comments (5)
This is the kind of article that makes me upset as a senior dev. It makes bold straw-man arguments to support its thesis. Junior devs won't recognize the straw-man arguments and may take some of this as dogma. This actually made me laugh:
If you think a ternary operator is "hard to understand", you shouldn't be a programmer. And the code is "heavier"? Ternary operators are lighter. It's "heavier" because there's a condition in it"?? And we've "grown the component size" by... what? A handful of characters?? C'mon, man...
Umm... no. We cannot all agree that the mere use of a ternary operator somehow is "not looking good".
This makes no sense. So... it will slow us down less to chunk all those styles somewhere else?? There is absolutely no justification given for this.
This is the kind of dogma that drags down dev teams. One person gets some ridiculous idea in his head like, "You should NEVER use inline styles!" and he tries to ram it down everyone's throat. Another person gets an idea like, "You should NEVER use CSS classes!" And they try to foist that rule on everyone.
But the fact is that nearly any dogmatic, inflexible "rule" is, in aggregate, wrong. Saying you "shouldn't be using this concept" is like saying, "Hammers are bad and screwdrivers are good. And you shouldn't be using the hammer if we're planning to build something productive."
If we were to follow the silly rules in this article, this would somehow be "wrong":
ALL I wanna do is float the
<div>to the right. So it's somehow "wrong" to put it right there? We should use CSS-in-JS to suck this one simple little property out of the<div>?? And that's somehow more scaleable? Cleaner? Easier to read??Agreed. The case for CSS in JS is not well made here. And the example of passing parameters is spurious: you can also pass a string direct to the inline style instead of using a ternary...
CSS modules worked really well for me. There are some limitations, but not enough to justify switching to the new and shiny. TBH I think it appeals mostly to those with limited CSS experience :/
Just to justify the comment about the spurious example - it's trivial to set an arbitrary background colour when using inline styles:
This article would have benefited from some peer review before being published but I think it's just intended as marketing material; so I guess they're not worried about the quality...
This is the first I've come across the term kebab-case. I'll have to use that one!
Good article!
forget react apps, I think it should not be used at all .