DEV Community: Ben Honeywill

A Quick Introduction to TypeScript for JS Devs

Ben Honeywill — Tue, 29 Mar 2022 19:27:51 +0000

We're going to start learning TypeScript by writing a very simple program that makes animal noises 🐽

Install TypeScript

Before you can use TypeScript, you'll need to install it. You can do this easily with npm.

npm install -g typescript

Getting started

The first thing you should know is that TypeScript is just a superset of JavaScript. This means that your existing JS code is also TypeScript code. TS just adds an additional layer on top, which is the type system.

To demonstrate this relationship between TS and JS, and to show how easy it is to move from JavaScript to TypeScript, we are going to start by building a simple website with vanilla JS.

Create 2 files, index.html and index.js

<!-- index.html -->
<!DOCTYPE html>
<html>
  <body>
    <script src="index.js"></script>
  </body>
</html>

// index.js
function animalNoise(animal, noise) {
  return `The ${animal} goes ${noise}`;
}

document.body.innerHTML = animalNoise("pig", "oink");

If you open index.html in your browser, you will see your tiny website in action.

Not very exciting is it? And we haven’t even used TypeScript yet. Let's fix that.

Sprinkling in some TypeScript

Migrating our website from JS to TS is pretty easy.

First, rename index.js to index.ts. If you open the site in your browser again and refresh, you'll see that this has broken it. The index.js that is referenced no longer exists.

Unfortunately, the browser does not understand the TypeScript type system, but it is very easy to compile a TypeScript file into a JavaScript file. Run the following command to compile your TypeScript file.

tsc index.ts

You will see that this command has generated our index.js file from the TypeScript file, and our website works again!

For now, the contents of the 2 files are virtually the same, but once we start using more TypeScript features you will see that they will get stripped out of the compiled JS file.

Adding in some types

So you might be wondering what the point of Typescript is if all of the TypeScript types get removed from the compiled code. Well, TypeScript gives you a lot more safety while you are coding and when you build your project. If TypeScript isn't happy with your code, it won't compile, and this can catch lots of bugs.

Let's add some types to our TypeScript file.

function animalNoise(animal: string, noise: string) {
  return `The ${animal} goes ${noise}`;
}

document.body.innerHTML = animalNoise("pig", "oink");

The two animal: string and noise: string declarations indicate that this function accepts two string arguments. TypeScript is also able to infer the return type of this function. If you hover over the function name in VSCode it will tell you that it returns a string.

You can run tsc index.ts again and see that it still compiles successfully. Notice that the types are stripped out of the compiled JS file.

Type Errors

Let's cause a type error. We have told TypeScript that this function accepts two strings, so let's give it a number instead 😈

function animalNoise(animal: string, noise: string) {
  return `The ${animal} goes ${noise}`;
}

document.body.innerHTML = animalNoise("pig", 42);

First of all, you should see that you get an error in your code editor.

This is one of the best things about the tooling around TypeScript! You get instant feedback when you make a mistake.

If you now try and rerun tsc index.js you will get a compilation error:

Argument of type 'number' is not assignable to parameter of type 'string'.

This error is good because TypeScript caught our mistake. Now we can fix it and try to compile it again.

Create your own types

The fundamental types like string, number or boolean are all very useful, but sometimes you need to define your own types to describe a more complex object.

Take our function for example, if we added a third argument, species, it might be a good idea to bring those 3 arguments together into a single object argument.

type Animal = {
  name: string;
  species: string;
  noise: string;
};

function animalNoise(animal: Animal) {
  return `${animal.name} the ${animal.species} goes ${animal.noise}`;
}

const peppaPig: Animal = {
  name: "Peppa",
  species: "pig",
  noise: "oink"
};

document.body.innerHTML = animalNoise(peppaPig);

There is a lot of new stuff going on here so let's break it down.

type Animal = {
  name: string;
  species: string;
  noise: string;
};

Here, we have declared a new type called Animal, which must have the 3 properties name, species and noise - all strings.

function animalNoise(animal: Animal) {
  return `${animal.name} the ${animal.species} goes ${animal.noise}`;
}

The animalNoise function now accepts a single argument, which must be an Animal.

const peppaPig: Animal = {
  name: "Peppa",
  species: "pig",
  noise: "oink"
};

Now we create the animal. const peppaPig: Animal defines the type of the variable. Try changing any of those values to something that isn't a string, or removing one of the properties and you will see that TS will give you an error.

If we compile the code again and refresh our browser window, everything should look good!

Classes

If you are familiar with es6 classes then you will feel at home using TypeScript classes, but there are a few additional syntax features that I would encourage you to go and research yourself.

TypeScript is smart, so it can compare the types you pass into a function and check if they match. So if you create a class that has name, noise, and species string properties, then TypeScript will know that it matches the Animal type and we can still use it in our function.

class Pig {
  name: string;
  noise = "oink";
  species = "pig";

  constructor(name: string) {
    this.name = name;
  }
}

const peppaPig = new Pig("Peppa");

document.body.innerHTML = animalNoise(peppaPig);

It's worth noting that in TS there is a shorthand for creating public properties from the arguments of the constructor. You could also write the above class like this.

class Pig {
  name: string;
  noise = "oink";
  species = "pig";

  constructor(public name: string) {}
}

What if we cause a type error to occur, for example instead of calling the property noise we call it sound? TypeScript we let us know.

We get a very useful error, telling us exactly what we have done wrong.

Property 'noise' is missing in type 'Pig' but required in type 'Animal'

Wrapping up

I hope this article has started to demystify TypeScript for you, and that you have started to get an idea of what it is and how it works. It's not as scary as it first seems!

Obviously, there is a lot more to TypeScript than what I have described here, I would encourage you to start building something in TypeScript and tackle any issues you have while you go. I think that is the best way to fully get to grips with all its features!

Easy "Blur Up" Image Loading with React Hooks

Ben Honeywill — Sun, 19 Jul 2020 20:57:26 +0000

Nb. I originally wrote about this technique on my blog, and there are interactive examples there so if you find this interesting check it out! 😊

What is "Blurring Up" an image?

Sometimes big images take a bit too long to load, and it can ruin users' first impressions of a site.

"Blurring Up" an image involves initially rendering a very small image, scaling it up and then applying a Gaussian Blur.

This means you get a low-res blurry representation of the image while the full-size image loads, and you never have to worry about your users looking at blank boxes where images should be.

Implementing this in React

I wanted to create a neat and tidy reusable React Hook that I could use in various components for Blur Up image loading. Here is what I ended up with.

import React from 'react';

const useProgressiveImg = (lowQualitySrc, highQualitySrc) => {
  const [src, setSrc] = React.useState(lowQualitySrc);

  React.useEffect(() => {
    setSrc(lowQualitySrc);

    const img = new Image();
    img.src = highQualitySrc;

    img.onload = () => {
      setSrc(highQualitySrc);
    };
  }, [lowQualitySrc, highQualitySrc]);

  return [src, { blur: src === lowQualitySrc }];
};

export default useProgressiveImg;

This is a hook which accepts two arguments: a low-quality image src, and a high-quality image src.

By default this hook will return the src of the low-quality pixelated image. Once the higher quality image has loaded, it will return that instead. This is achieved by adding an event listener to a new Image object. The src attribute of this Image is set to the src of our high quality image, so the event listener fires once the full-size image has loaded.

Once that image has loaded we switch from returning the pixelated image to returning the full-size image.

You may have also noticed that this hook returns a second value, which is an object containing a value I have called blur. We can use this to know whether or not we need to "blur" the image. If the current src being returned is that of the low-quality image, then we should blur the image, as that is the nasty pixelated one.

Usage

Here is an example of how to use this hook to get the desired "blur up" effect.

import React from "react";
import useProgressiveImg from "./useProgressiveImg";

const BlurredUpImage = () => {
  const [src, { blur }] = useProgressiveImg(
    "./tiny.jpg",
    "./large.jpg"
  );

  return (
    <img
      src={src}
      style={{
        width: 200,
        filter: blur
          ? "blur(20px)"
          : "none",
        transition: blur
          ? "none"
          : "filter 0.3s ease-out"
      }}
    />
  )
}

In this example tiny.jpg should be a very small version of the full-size image large.jpg.

I have used inline styles here for simplicity's sake, but you could also use the blur value to toggle a class, or pass it in as a prop to a styled component. The important thing here is that we are adding a CSS blur() filter if the image hasn't loaded yet. The transition makes the transition between the blurred and non-blurred states nice and smooth.

Thanks for reading

Let me know what you think of this handy hook in the comments.

Protecting your GraphQL Server from Dangerous Queries

Ben Honeywill — Wed, 01 Apr 2020 23:46:27 +0000

Let's imagine that we are building a GraphQL API for listing recipes. Every recipe contains ingredients, and an ingredient can belong to lots of different recipes. A simple GQL schema for our API might look something like this.

type Query {
  getRecipes: [Recipe]!
}

type Recipe {
  id: ID!
  name: String!
  ingredients: [Ingredient]!
}

type Ingredient {
  id: ID!
  name: String!
  recipes: [Recipe]!
}

One of the best things about GraphQL is that we can query for exactly the data we want. This is a great developer experience, but we have to consider how this can effect the performance and security of our server. You may have noticed that our schema has a circular relationship between Recipe and Ingredient. This is interesting, as it means we can form heavily nested queries. I will show you what I mean.

query {
  getRecipes {
    recipes {
      ingredients {
        recipes {
          ingredients {
            recipes {
              ingredients {
                # ... and so on
              }
            }
          }
        }
      }
    }
  }
}

This query may look amusing and harmless, but performance-wise it is very expensive to run. A malicious user could send nested queries like this to your API and crash your entire server.

Thanks to a handy npm package called graphql-depth-limit this problem is easy to fix. First, you will need to decide on a suitable depth limit for your schema. For our recipe schema it makes sense to have a maximum query depth of 2, as that will allow us to make the following query, but not any deeper.

query {
  getRecipes {
    name
    ingredients {
      name
    }
  }
}

You should decide what query depth is right for your own GQL schema. Hooking up graphql-depth-limit is really easy, all you have to do is pass it into the validationRules configuration option of your GraphQL server. If you use apollo-server like I do then that looks like this.

const { ApolloServer } = require("apollo-server");
const depthLimit = require("graphql-depth-limit");
const { typeDefs, resolvers } = require("./schema");

const server = new ApolloServer({
  typeDefs,
  resolvers,
  // Allow a maximum query depth of 2
  validationRules: [depthLimit(2)]
});

Depth limiting your schema really is that easy, and now we are protected from malicious circular query attacks.

Query Cost Analysis

Bear in mind, depth level is not the only cause of an expensive query. Queries that aren't particularly nested can still hit your database, server, and network hard if they are fetching thousands of records.

graphql-validation-complexity is a package that can help us quantify the complexity of our queries, and reject any requests that don't pass the validation. By doing this we can protect our GraphQL server from very expensive queries that graphql-depth-limit won't catch.

Let's look at how you would implement Query Cost Analysis with graphql-validation-complexity. The library does a good job of having sane default behaviour, which makes it a plug-and-play solution for the most part. The most simple implementation looks like this.

const { ApolloServer } = require("apollo-server");
const depthLimit = require("graphql-depth-limit");
const { createComplexityLimitRule } = require("graphql-validation-complexity");
const { typeDefs, resolvers } = require("./schema");

const server = new ApolloServer({
  typeDefs,
  resolvers,
  validationRules: [
    depthLimit(2),
    // Allow a maximum query cost of 1000
    createComplexityLimitRule(1000)
  ]
});

Here we've set the maximum query complexity to 1000, you will have to experiment by reviewing the complexity of your current queries to determine a sane complexity limit for your own GraphQL server.

So where does this complexity number come from?

graphql-validation-complexity applies different "costs" to the different fields in your schema such as objects and scalars, and "cost factors" for lists. It uses these costs and cost factors to estimate the complexity of any given query.

Of course, the library doesn't know anything about your application-specific logic - you could have a list in you schema that is particularly costly to fetch. This is why graphql-validation-complexity allows you to set custom costs and cost factors on fields via schema directives.

directive @cost(value: Int) on FIELD_DEFINITION
directive @costFactor(value: Int) on FIELD_DEFINITION

type Query {
  getRecipes: [Recipe]!
}

type Recipe {
  id: ID! @cost(value: 10)
  name: String! @cost(value: 10)
  ingredients: [Ingredient]! @costFactor(value: 50)
}

type Ingredient {
  id: ID! @cost(value: 10)
  name: String! @cost(value: 10)
  recipes: [Recipe]! @costFactor(value: 50)
}

Tagging your schema fields with specific costs like this means that graphql-validation-complexity can more accurately estimate the complexity cost of a query.

The library has even more configuration options that you can set, for example how errors are handled when a query cost is too high... Check out the docs to find out more.

Thank you for reading, this article was originally posted on my blog.

How to Style Your React Components

Ben Honeywill — Wed, 25 Mar 2020 00:09:03 +0000

With all of the different options available to us for styling our React components, it can be overwhelming to know what option is right for our individual use-cases. That's why I'm writing this post. I'm going to go over some of the most popular and prevalent options available to us for styling React components. What are the pros and cons of each? And which should you use in your app?

CSS
Inline Styles
CSS Modules
CSS in JS
TLDR

Normal CSS

The first option available to all React developers for styling our components is the most obvious one. Plain, old, simple CSS.

What makes CSS great?

Ease of use

We often over-complicate things by reaching for fancy solutions to problems we don't have. CSS is one of the fundamental building blocks of the web, which means that you don't have to worry about npm package versions or complicated build processes. You just have to link to your CSS file in the head of your HTML page and voila, you are ready to go.

<html>
  <head>
    <!-- That was easy! -->
    <link href="main.css" rel="stylesheet">
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

Longevity

When it comes to some of the other styling methods in this article, you would be forgiven for wondering if they'll still be around in 2 years. There's nothing worse than designing your whole architecture around a library or framework only for that library to fall out of favour in the JS community shortly thereafter. With CSS you will never have this problem, it is built into every browser and isn't going anywhere.

What's not so good about CSS?

No access to the power of JS

We are writing React applications, and as such we want to be able to utilise the power of JavaScript wherever possible! CSS in JS libraries provide some really useful features that allow us to compute CSS properties using JavaScript right inside of our style declarations, but with vanilla CSS we have to do everything via HTML classes.

This means that to change styles based on props, you have to write some quite verbose code to change the className of an element.

import React from "react";

const Button = props => {
  const classNames = ["button"];

  if (props.large) {
    classNames.push("button--large");
  }

  if (props.rounded) {
    classNames.push("button--rounded");
  }

  if (props.color) {
    classNames.push(`button--${props.color}`); 
  }

  return (
    <button className={classNames.join(" ")}>
      Click me
    </button>
  );
};

If you choose to go the plain CSS route your app will soon become littered with if statements like this. There are packages to help with this specific issue though, like classnames.

This pain point could also be somewhat alleviated by the use of a CSS preprocessor like Sass that would give you access to functions and mixins. It is worth bearing in mind however, that the while using functions in these preprocessors does tidy up your codebase, the CSS output can become very bloated, increasing your page load times.

You may need additional build configuration anyway

Sure, adding CSS to your React application is as simple as a single line addition to the HTML file. However, if you want to use a preprocessor like Sass, need CSS auto-prefixing, or want to concatenate different CSS files together... you are probably going to want some kind of a build process anyway.

The good news is that if you are writing a React application you probably have a build process set up that you can already hook into. If you are using create-react-app or Next.js for example, the in-built Webpack configuration will already handle importing CSS files directly in your React components.

import React from "react";

import "./box.css";

const Box = () => (
  <div className="box">
    <p className="box-text">Hello, World</p>
  </div>
);

It is difficult to write modular plain CSS

CSS was not designed to be used in a component-based application, it was designed to style documents and webpages. In these environments CSS's global namespace and cascade can be powerful tools, but in a component-based app the global nature of CSS starts to get in the way.

Whenever you are writing styles for a new component you have to be wary about how these new styles might affect other components in your application. Having a strict naming convention for your CSS class names becomes a necessity.

When writing plain CSS I like using the Block, Element, Modifier (BEM) methodology. BEM ensures that your CSS remains as modular as possible, and also discourages nested selectors which give your style rules high specificities that are difficult to overwrite. If you are unfamiliar with BEM you can read this article for a quick introduction to the idea.

Inline Styles

The next way you can style your React components is by using Inline Styles. In React you can
add styles directly to an element via the style prop. This is probably the easiest and quickest
to use of all the methods described in this post but is also the most limited.

Why use Inline Styles?

Quick to set up and use

Inline Styles require no configuration, they are built straight into React. You can simply pass your styles directly to an element via the style prop, which should be a JavaScript object whose keys are the camelCased version of the style name.

import React from "react";

const boxStyle = {
  border: "1px solid #f7f7f7",
  borderRadius: "5px",
  padding: "20px"
};

const boxTextStyle = {
  fontSize: "15px",
  textAlign: "center"
};

const Box = () => (
  <div style={boxStyle}>
    <p style={boxTextStyle}>Hello, World</p>
  </div>
);

Full access to JavaScript within the style declarations

One of the big downsides of CSS that we talked about was that there is no access to JavaScript to help us do some of the heavy lifting inside our stylesheets. Remember the example with all the if statements that toggled class names? Well... that becomes much easier to do when you have access to JavaScript functions!

import React from "react";

const styles = props => ({
  fontSize: props.large ? "20px" : "14px",
  borderRadius: props.rounded ? "10px" : "0",
  background: props.color
});

const Button = props => {
  return <button style={styles(props)} />;
};

No cascade, no global styles

Unlike with CSS, Inline Styles are passed straight to the HTML element rather than using a class. This lends itself much better to the component-based paradigm we use when writing React applications. We no longer need to worry about class name collisions or styles unintentionally leaking into other components. Everything is neatly scoped inside of a component.

What are the drawbacks of Inline Styles?

Clunky to write

This point is subjective I admit, but I find the JavaScript object notation and camelCase key names very clunky to write. You have to put all of the values inside of strings, and I've also yet to find any plugins for my code editor that offer a similar developer experience to when writing CSS.

Unable to access basic functionality from CSS

This is the biggest drawback to using Inline Styles. Here is a list of some of the CSS features that are unsupported when using Inline Styles:

Media queries
Keyframe animations
Pseudo-elements (:after, :before)
pseudo-selectors (:hover, :focus)

The absence of media queries alone is a deal-breaker for any application that needs to be responsive, and you don't want to have to start handling mouse and focus events to style hover and focus states when this is so easy to do in CSS.

That being said, If you are interested in finding out how to emulate media queries in your React application using only JavaScript, check out this article (Developing responsive layouts with React Hooks) that I wrote for LogRocket.

In general, I would avoid Inline Styles

Inline Styles can be great for quick and dirty proof of concepts or demo purposes but for me, the lack of essential CSS functionality like Media queries, animations and hover states is a deal-breaker. I will nearly always reach for one of the other methods.

CSS Modules

The next option is CSS Modules, and it's one of my favourites. Writing CSS Modules is just like writing normal CSS with one important difference: all the styles you write will get locally scoped class names, so you no longer have to worry about class name collisions or leaky styles.

/* box.css */

.box {
  border: 1px solid #f7f7f7;
  border-radius: 5px;
  padding: 20px;
}

.boxText {
  font-size: 15px;
  text-align: center;
}

import React from "react";

import styles from "./box.css";

const Box = () => (
  <div className={styles.box}>
    <p className={styles.boxText}>Hello, World</p>
  </div>
);

When importing a CSS Module from a JavaScript file, it exports an object with keys matching the classes declared within the written CSS. The values of these keys, however, are unique, which means that your CSS is automatically scoped locally to your component for you.

What's so good about CSS Modules?

All the benefits of Vanilla CSS

Anything you can do in vanilla CSS, you can do in CSS modules - you are just writing CSS! CSS Modules can even be configured to work with your favourite CSS preprocessor like Sass.

Great for building component-based CSS architectures

CSS Modules have all the benefits of CSS but solve the biggest drawback. CSS Module styles are locally scoped to your component. This makes writing maintainable and modular CSS much easier and more enjoyable. Instead of worrying about using a CSS naming methodology like BEM you can just name your classes whatever makes sense in the context of your component.

And don't worry, there is an escape hatch for writing global styles as well, should you need it.

:global {
  .center {
    text-align: center;
  }
}

The footprint left on your app is small

Your codebase will still be made up of plain CSS files, so even though you have to add a build step and slightly change the way you import and apply your styles, the footprint left on your app is small. This means that if you ever need to pivot away from CSS Modules in the future, the transition should be quite painless.

What's not so good about CSS Modules?

You need to set up your build process to handle CSS Modules

To make use of CSS Modules you do need to configure your build process. Luckily in Webpack this is pretty easy to do using css-loader.

Even better, create-react-app now supports CSS Modules out of the box. You just have to be sure to name your files with the .module.css suffix.

No access to JS from within the styles

CSS Modules do suffer from one problem in the same way as plain CSS: you can not access JS from within your style declarations to carry out more complex styling logic. This leads us nicely on to the next solution.

CSS in JS

CSS in JS is an umbrella term used to describe JavaScript libraries that allow you to declare your CSS inside of your JavaScript files, similar to Inline Styles, but with added benefits. I'm going to show you the most popular one, Styled Components, but it's worth bearing in mind there are many more (Emotion, JSS, Aphrodite, etc.)

Styled Components

Styled Components is perhaps the most popular CSS in JS library. With Styled Components you create... well, styled components. Let's take a look.

import React from "react";
import styled from "styled-components";

const BoxWrapper = styled.div`
  border: 1px solid #f7f7f7;
  border-radius: 5px;
  padding: 20px;
`;

const BoxText = styled.p`
  font-size: 15px;
  text-align: center;
`;

const Box = () => (
  <BoxWrapper>
    <BoxText>Hello, World</BoxText>
  </BoxWrapper>
);

As you can see we use the library to create React components that have styles. Style Components uses the es6 Tagged Template Literal syntax to create components and turns the styles into real CSS.

Why use Styled Components?

Easy to pick up if you already know CSS

Because the JavaScript is turned into actual CSS you can still do everything in Styled Components that you can in CSS. This includes media queries, pseudo-selectors, and animations.

import styled, { keyframes } from "styled-components";

const rotate = keyframes`
  from { transform: rotate(0deg); }
  to { transform: rotate(360deg); }
`;

const Rotating = styled.div`
  animation: ${rotate} 2s linear infinite;

  @media(max-width: 500px) {
    display: none;
  }
`;

Rather than using the clunky camel-case properties that we saw with inline styles, with Styled Components you can just write normal CSS. It's easy to pick up if you already know CSS. There are also great plugins for most code editors that provide a similar developer experience to when writing CSS, including syntax highlighting and auto-completion.

Full access to JavaScript's power

Because we are using a CSS in JS solution we also have full access to the JavaScript language to apply conditional logic to our styles. A component's props are passed into calls to styled, and we can access them through functions that we declare directly in our style declarations. This is super powerful! It means we can run whatever JavaScript code we like to determine how a component should be styled.

import React from "react";
import styled from "styled-components";

const StyledButton = styled.button`
  background: ${props => props.color};
  font-size: ${props => props.large ? "18px" : "14px"};
  border-radius: ${props => props.rounded ? "10px" : "0"};
`;

const BigRoundBlueButton = () => <StyledButton color="blue" large rounded />;

Styled Components also has built-in support for theming, using React's context API. This makes it a breeze to implement features like a dark mode in your application.

import styled, { ThemeProvider } from "styled-components";

const Button = styled.button`
  color: ${props => props.theme.primary};
`;

const theme = {
  primary: "#000000"
};

const App = () => (
  <ThemeProvider theme={theme}>
    <Button>Click me!</Button>
  </ThemeProvider>
);

Component first, React first

Unlike with plain CSS your styles are tightly scoped to the component that you create when you declare them, solving the global namespace problem we've talked about previously.

In fact, Styled Components even goes one step further. Rather than just creating CSS you are also creating the actual React components that become part of your application. This makes this library perfect for building UI libraries or creating atomic components that you want to use throughout your application.

Automatic critical CSS

Styled Components is also very smart and makes a lot of optimisations to your application's code to improve perceived performance. One of these optimisations that I'd like to draw your attention to (because it's so cool), is that Styled Components will automatically inline the CSS for the above-the-fold content on your webpage.

styled-components keeps track of which components are rendered on a page and injects their styles and nothing else, fully automatically. Combined with code splitting, this means your users load the least amount of code necessary.
Styled Components' documentation

What's not so good about Styled Components?

It adds a big dependency to your project

Bringing Styled Components into your project adds an extra dependency for you to manage, and unlike CSS Modules, Styled Components leaves a very large footprint on your application. An application that uses Styled Components becomes riddled with calls to styled, and if in the future you decide to migrate away from Styled Components, it could be a potentially daunting task.

It's also worth mentioning that the landscape of CSS in JS libraries is quite turbulent. New libraries with new ideas seem to appear regularly, so it might be a bit too early to bet the future of your application on Styled Components.

TLDR

We've analysed 4 different methods of styling your React components. CSS, Inline Styles, CSS Modules, and CSS in JS (styled-components).

CSS Modules provide a great balance between being future proof and being useful. They help you write modular styles by keeping the class names of your CSS locally scoped to a component.
Styled Components will give you the most functionality, as well as great optimisation features and access to the rich ecosystem of CSS in JS libraries. This is at the cost of taking over your application. Your app will become as much a Styled Components app as it is a React app. It is worth also looking at some other CSS in JS libraries (I like Emotion a lot!)
Plain CSS is great if you want to keep things simple, but be aware that when writing styles for a componentized application in CSS a consistent class naming methodology is a necessity - try BEM.
Inline Styles are great for quick demo projects or proof of concepts but the lack of essential CSS features like media queries means that another option is almost always preferable.

This article was originally posted on my blog.

Thank you for reading! Happy to answer any questions.