Is there an inherent problem with dynamically generating tailwind class names in a component?
I wanted to make the button color configurable. This is mostly from the auto-generated core_components.ex. I only added the “color” attribute, so I could say something like <.button color="red">.
attr :type, :string, default: nil
attr :class, :string, default: nil
attr :color, :string, default: "zinc"
attr :rest, :global, include: ~w(disabled form name value)
slot :inner_block, required: true
def button(assigns) do
~H"""
<button
type={@type}
class={[
"phx-submit-loading:opacity-75 rounded-lg bg-#{@color}-900 hover:bg-#{@color}-800 py-2 px-3",
"text-sm font-semibold leading-6 text-white active:text-white/80",
@class
]}
{@rest}
>
<%= render_slot(@inner_block) %>
</button>
"""
end
The HTML source of the page looks OK to me:
<button class="phx-submit-loading:opacity-75 rounded-lg bg-red-900 hover:bg-red-800 py-2 px-3 text-sm font-semibold leading-6 text-white active:text-white/80">
Speichern und beenden
</button>
<button class="phx-submit-loading:opacity-75 rounded-lg bg-zinc-900 hover:bg-zinc-800 py-2 px-3 text-sm font-semibold leading-6 text-white active:text-white/80" name="Weiter">
Speichern
</button>
But the colors don’t show up unless they are also explicitly used somewhere else.
There is essentially the same problem with my attempt to define a component for a grid column with configurable span:
@doc """
Renders a grid column.
"""
attr :span, :string, default: "1"
slot :inner_block, required: true
def gridcol(assigns) do
~H"""
<div class={"col-span-#{@span}"}>
<%= render_slot(@inner_block) %>
</div>
"""
end
The col-span seems to be ignored although the HTML source looks Ok.
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.
3 Likes
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)","
]
4 Likes
Ok, that seems doable.
I’ll try it out, thanks!
1 Like
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)
1 Like
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.
1 Like
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.
