Using "generated" class names in Tailwind under Phoenix 1.7+

Ya, Tailwind won’t work with dynamic classes that way unless you list out all of the possibilities somewhere. From the docs:

Tailwind CSS works by scanning all of your HTML files, JavaScript components, and any other templates for class names, generating the corresponding styles and then writing them to a static CSS file.

So it does not see the literal strings bg-#{@color}-900 and col-span-#{@span} a valid class names so it ignores them.

If you want to provide custom colors I would use vanilla CSS. Another hacky solution would be to just list all possible classes in a comment, though that isn’t a great solution.

Huh. That’s inconvenient, because it much diminishes the usefulness of components.
I’m loath to put explicit styling in my HEEX templates, so I had hoped to use the components for this kind of dynamic HTML processing.

So it seems the best way would be define a specific component for each variant, duplicating the HEEX code every time…
i.e. <.button_red>, <button_blue>, …

And I can’t even abstract all those from a single general button function inside the component, because I have to completely write out the HEEX so it can be scanned.

ergh

You can declare them in the safelist section of your Tailwind config file (default: assets/tailwind.config.js). For example:

module.exports = {
  content: ["./js/**/*.js", "../lib/*_web.ex", "../lib/*_web/**/*.*ex"],
  theme: {
    // ...
  },
  safelist: [
    "bg-primary",
    "bg-secondary",
    "bg-accent",
    "bg-neutral",
    "bg-info",
    "bg-success",
    "bg-warning",
    "bg-error",
  ],
  plugins: [
    // ...
  ],
};

EDIT: After thinking about it and RTFD, it turns out you can use regex as well:

  safelist: [
    "bg-(primary|secondary|accent|neutral|info|success|warning|error)","
  ]

Ok, that seems doable.
I’ll try it out, thanks!

That’s cool, I wasn’t aware of safelist, though it’s still just a “cleaner” solution over writing them all out in a comment—a bit unscalable if you have a lot of colors and have to cover bg, text and so on. I’m seeing the docs even say it’s a last resort. Though if you are only doing the background color and text color, it could be ok.

@StephanLehmke At first I was assuming you were talking about allowing users to provide custom colors but if you just want different colour buttons, it’s far more preferable to define them either, as you mentioned, as different components, or use an attribute. It’s probably even better to defined them based on their purpose rather than colour, but that is up to you. You shouldn’t need much duplication.

def button(%{type: :primary} = assigns) do
  assigns = assign(assigns, :class,  "text-blue-50 bg-blue-900")

  ~H"""
  <.button class={@class} />
  """
end

def button(%{type: :muted} = assigns) do
  assigns = assign(assigns, :class,  "text-zinc-700")

  ~H"""
  <.button class={@class} />
  """
end

def button(assigns) do
  assigns = assign_new(assigns, :class, fn -> "text-zinc-900 text-zinc-100" end)

  ~H"""
  <button class={@class}>
    <%= render_slot(@inner_block) %>
  </button>
  """
end

# Usage:

<.button type={:primary} />

(I didn’t try out that code but it’s the general idea)

Of course, in the end the naming needs to be based on purpose; that just was the first thing to try out.

The col-span thing is probably a better example, because I plan to use a grid with 12 columns so I can switch between 2, 3, 4 column mode as needed.

The idea of doing abstraction by calling functions from within the HEEX sigil instead of calling a function that tries to generate classes dynamically via string comprehension makes a lot of sense.

In the end it’s probably not that much of a hardship because indeed, the notation should be tailored to the intended use, which won’t leave too many valid use cases for dynamically generated class names.

I just was appalled by the prospect of littering my HEEX templates with explicit <div class="... because it was somehow impossible to abstract away without enormous effort.

To be fair, I think the term ‘last resort’ may be a bit dramatic, as I was previously creating templates with the required classes in them just so they would be included, which I think is far more clunky than just safelisting.

But I took another look at the docs, and you can use regex to prevent unnecessary repitition, so I edited my post with an example that decreases the, ahem, verbosity of my intial suggestion.

Definitely should be avoided if possible, but the option exists for a reason.

ie, last resort I certainly wasn’t implying it’s a useless option, but “last resort” to me just means you can’t think of any other way. There are certainly other ways here as requiring different pre-defined styled buttons is very common usecase. Of course if you want to go the route of just defining dynamic classes, you can. I think there is a JS lib that allows you to do this now? I can’t remember what it’s called, just saw something on YouTube recently but I generally don’t keep up with that world. I’m just personally not a fan as it feels a little brittle to be directly manipulating TW classes from the outside but it’s not the worst thing in the world. It sure makes changing the colour later on a bit of a hassel, though.

Just an update for the post-1.8 world, in assets/css/app.css after the tailwindcss is imported:

@source inline("bg-{zinc,red,blue,yellow}-{800,900}");

BUT, “the right way”™ is to use the variants, which you’d color with a Daisy theme or override yourself in assets/css/app.css, and then which you’d add explicitly into the variants map in CoreComponents.button which means they’re automagically picked up by the CSS build without having to add a @source line for them.