Using Tailwind CSS in Rails

TailwindCss has been around for a while and it’s getting more popular every day. Not only because of a solid set of “utility classes” (one-off Css classes that only do one thing), but also because of a solid build tool/configuration based on plugins that can be easily extended upon (if you know Javascript). As a designer, I like the solid default “theme” it comes with too. Out of the box Tailwind comes with a solid set of colours, which then in turn are used for the color, background and border-color properties.

Installing Tailwind in your Rails app

Tailwind Css is easily installed using Yarn. This assumes you have Webpacker and Yarn installed.

$ yarn add tailwindcss

And add tailwindcss: {} to your .postcssrc.yml file.

If you want to customise Tailwind’s default settings, you can run:

$ ./node_modules/.bin/tailwind init app/javascript/stylesheets/tailwind.js

But if you want to get a headstart, it’s even easier to either use Sjabloon or use its LITE version. With either version Tailwind is all set up for you.

Creating UI with Tailwind is fast

The many different classes are ideal to be just added right in the HTML. I often start this way. It makes it super quick to create a layout for a page or a UI component.

This could look something like this:

<%= link_to "Go home", root_path, class: "inline-block w-full mb-4 px-6 py-8 text-2xl font-bold text-center text-blue-500 bg-blue-100 rounded sm:w-1/2 sm:mr-2" %>

The order of classes is not random here. It starts with the sizing/width/height selectors first as they directly impact the painting/rendering of the elements onto the page. The sm: prefixed classes are responsive classes and are only applied when that breakpoint is reached—super smart! Auto-refreshing the page allows you to quickly see how your new component looks. Text too light? Change it to text-blue-600.

When it’s just a component I use once or twice one a page (literally or as part of a partial) I leave it just as is. But once I am about to reuse the component elsewhere in the app, I extract it out into a standalone css class.

Like so:

.text-block {
  @apply inline-block w-full mb-4 px-6 py-8;
  @apply text-2xl font-bold text-center text-blue-500;
  @apply rounded;
  @apply bg-blue-100;

  @screen sm {
    @apply w-1/2 mr-2;
  }
}

You can see how the order is kept the same as the inline version. This is on purpose, as I just have to copy/paste the entire list of classes, add breaks and add Tailwind’s @apply. The grouping here is intentional too. You could as easily just add all classes to one @apply line, but grouping it like this, makes it just a bit more organised.

Structuring your styles and stylesheet

The stylesheet itself is structured too—though it’s likely that early on you don’t add too much in your external stylesheet. This ordering is loosely based on ITCSS (coined by Css wizard Harry Roberts). The thought behind it is, you go from low specificity to high specificity. Not coincidentally Tailwind is perfect to follow this methodology.

@import "tailwindcss/base";

@import "settings";
@import "base";
@import "objects";
@import "components";

@import "tailwindcss/utilities";

Let’s go over each of these:

• tailwindcss/base is Tailwind’s browser normalisation (giving you a standard default stage across browsers).
• settings is where you define variables, eg. --brandColor (Sjabloon uses Css root vars for these).
• base is where you add your unclassed HTML elements, eg. body {}
• objects is the place design-patterns without “cosmetics”, eg. list-reset
• components is for all your UI components and likely the file (with subfiles) with the most going on. This is where you add your reusable components.
• tailwindcss/utilities are all the utility classes coming from Tailwind and can be used to override specific things of “object” or a “component”.

Keeping to conventions and your files organised like these, make for clean and clear stylesheets. Easy to create and to add changes even months after you touched the codebase.

The best practices described here can be applied to any Css codebase and are not really specific to Ruby on Rails apps. These are general best practices for creating and managing stylesheets (based off of more than 15 years of writing Css).