DEV Community: Brendan Carney

How We Use Tailwind in Components

Brendan Carney — Sun, 22 Mar 2020 17:43:51 +0000

I wrote about Why We Use Tailwind at ConvertKit. This is about how we use Tailwind in our components.

The short version is that we use the tailwind classes directly in our components:

const Button = (props) => 
  <button {...props} className="px-4 py-2 bg-gray-700 text-white" />

But, we also want our components to do a little more. We want to work with a fixed set of colors, sizes, etc. to make development easier and our UI more consistent. That way, our developers can write code like this:

<Button color="red" size="lg">Save Form</Button>

instead of having to repeat classes all the time:

<Button className="bg-red text-white px-4 py-2"/>

Here's how we do that:

const DEFAULT = "border border-solid border-transparent";

const COLORS = {
  green: "text-white bg-green-400 hover:bg-green-500",
  red: "text-white bg-red-400 hover:bg-red-500"
};

const Button = ({ color, children, className, ...props }) => {
  className = [className, DEFAULT, COLORS[color]].join(" ");

  return (
    <button {...props} className={className}>
      {children}
    </button>
  );
};

This is a simplified example of our actual component that's only handling the different colors. We have a default set of classes that all buttons have (DEFAULT), then, we have an object representing the different colors (COLORS). When someone passes red as the color prop, we use the classes that match that key: COLORS["red"]. We merge all this together with the className prop that that you can also pass to our component to add additional classes if necessary.

// A red button with margin at the bottom
<Button color="red" className="mb-2"/>

We follow the same pattern for sizes, variants, and different states of our components.

How are you using Tailwind in React components?

P.S. We're hiring a few full stack engineers at ConvertKit. Learn more here convertk.it/engineer

Why We Use Tailwind at ConvertKit

Brendan Carney — Wed, 18 Mar 2020 11:53:44 +0000

When my coworker first introduced me to Tailwind (hi Mark), I had the same reaction as most people that hadn't used a utility-first CSS framework before. Why do we need this? If we're writing solid CSS everywhere, and all following the same patterns, conventions, and rules, and keeping our UI consistent across different teams, then we don't need a framework that pollutes our HTML with all these non-semantic class names.

Then I took another look at our CSS...

We used bootstrap, BEM, OOCSS, some css modules, and many other patterns and conventions across the application. No one really knew which one was the right one to use at any given time. No one knows what is used and unused. Our CSS had become an append-only stylesheet.

So we decided to give Tailwind a shot and styling our application immediately became easier for everyone. We no longer need to think about what conventions we're following, what to name things, or where to put styles. We don't have to worry about breaking styles somewhere else in the application or our stylesheets continuing to grow unchecked. We only need to follow a few simple rules:

Use our component library
Use Tailwind
Fallback to inline styles

And that's it.

There are many articles about why you should use Tailwind, but why do we use Tailwind? Because it simplifies just about everything when it comes to styling UI across our teams. It eliminates decisions of where to put things or how to write them. It comes with great documentation. For teams, especially with varying backgrounds and UI skill levels, Tailwind is a massive productivity boost.

Why do you use/not use Tailwind?

P.S. We're hiring a few full stack engineers at ConvertKit. Learn more here convertk.it/engineer

Two Components are Better than One

Brendan Carney — Tue, 17 Mar 2020 12:29:17 +0000

Component based libraries like React are great in part because they allow us to encapsulate a piece of UI, and reuse it across our application. This allows us to have consistent UI, and makes tweaking styles easy. But, reusability can be taken too far. It might be tempting to only have one Button in your component library that can handle everything, but you can easily end up with something like:

<Button
  icon="gear"
  iconPosition="left"
  size="small"
  variant="outline"
  isLoading
  fullWidth
  {...andManyManyMore}
/>

// Detect dark theme var iframe = document.getElementById('tweet-1002110517094371328-28'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1002110517094371328&theme=dark" }

What was once a simple Button now has props for every imaginable use case), making it hard to maintain or change.

Sometimes, it's better to have a few more components for specific use cases instead of one component that handles everything. Here are a few examples where I've created multiple components instead of adding more props to one:

Instead of a Button that can have text or just an icon, create a normal Button and a separate IconButton. This way, you won't have to special case spacing when there is text with an icon, and you can easily build an API that forces you to add a label for accessibility in your IconButton.

Instead of a SelectMenu component that can handle both single selection and multiple selection, split into SelectMenu and MultiselectMenu. The logic around these is different enough that maintenance and styling is much simpler when they are kept separate.

What are some other examples of components trying to do too much?