Why you shouldn’t use inline styling in production React apps

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.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

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.

Cut through the noise of traditional React error reporting with LogRocket

LogRocket is a React analytics solution that shields you from the hundreds of false-positive errors alerts to just a few truly important items. LogRocket tells you the most impactful bugs and UX issues actually impacting users in your React applications. LogRocket automatically aggregates client side errors, React error boundaries, Redux state, slow component load times, JS exceptions, frontend performance metrics, and user interactions. Then LogRocket uses machine learning to notify you of the most impactful problems affecting the most users and provides the context you need to fix it.

Focus on the React bugs that matter — try LogRocket today.