Can we solve the tailwind-interpolation-problem with a macro?

Oh my god, just banged my head for a few hours to understand that this is happening.

The thing is that this is not only not consistent, if you use same classes elsewhere, it will work (this also includes cached builds), but it also doesn’t show any kind of errors or warnings.

Actually as it currently stands, it seems that the limitation is that the string should be known at compile-time, things such as this work:

<div class={[@badge_type]}>
</div>

badge_type = get_badge(type)
assign(socket, badge_type: badge_type)

defp badge_type (type) do
    case type do
      :success -> "badge-success"
      :warning -> "badge-warning"
      :error -> "badge-error"
      :inactive -> "badge-ghost"
      :not_found -> "badge-info"
    end
  end

I have both the cases where a separate .heex file is used and when render/1 from an .ex file is used, and both seem to be working when the strings are known at compile-time. Looking at this now, it seems that the configuration watches in .ex files too:

content = [
  ...
  "../lib/*_web/**/*.*ex"
]

Have you found any solutions so somebody else would not stumble onto this bug?

Have a look at: Detecting classes in source files - Core concepts - Tailwind CSS

If you really need to have some classes, you can safelist them (see further on that page).

Basically, tailwind creates minimal css files by only including the class you’ve used. It can’t guess what classes you need.

I think my tails library could be a good place to put this solution: Tails - Tailwind & Tailwind Component Utilities

We can make classes into a macro instead of a function, and support something like this:

classes(["foo-#{x}", ...], x: [1, 2, 3, 4, 10, 24, 96])

Then it would yell if you interpolate a variable in your classes but don’t provide a list of possible values. Then it would write the file that you’ve mentioned.

This is a great resource, but the reality is that the most likely case is the one I stumbled across, where you have to invest a lot of time to understand what is happening.

It would be great if the tailwind elixir library could somehow detect and warn the user that class string interpolation can impact directly tailwind classes when used in conjunction with phoenix.

I think having it more prominently documented would go a long way. As it stands, as linked by @tcoopman, the Tailwind documentation mentions it three sections in and a good scroll-length down the page. For Phoenix users, phx_new could maybe add a comment about it to app.css and/or tailwind.config since so many people run into this (I did too).

Warning via a macro would probably be really tricky as interpolating non-tailwind classes is perfectly valid. It would be hard to reliably judge what is and isn’t a Tailwind class.

EDIT: I guess you could warn on interpolation so long as there is way to turn it off since this is one of those things that once you know, you know.

I think this is totally doable, especially with the tools elixir has at disposal. Think of it the following way:

1. Magic for finding dynamic class content;
2. Magic for finding interpolated strings in dynamic classes;
3. Use a opt-out approach where you always warn the user about the potential problem, then offer him a way out, for example by using a ~dont_care sigil;
4. Make it globally configurable if you don’t care at all.

I think this is very important, especially for beginners that have a lot of complexity without this small implementation detail that is extremely hard to trace down.

I wasn’t saying that any of that was hard. What’s potentially hard is determining what is an isn’t a Tailwind class, especially since TW class names are highly configurable. But ya, so long as you could turn it off it should be fine. And obviously not fire if you’ve used --no-tailwind.

Plus this is perfectly valid:

color =
  case assigns.color do
    :green -> "bg-green-500 text-green-50"
    # ...
   end

assigns = assign(assigns, :color, color)

~H"""
<p class={"font-bold #{@color}"}>foo</p>
"""

But yes, so long as there is a way to turn it off it would be good.

Indeed, this is very similar to the example I posted above.

What I want to focus on is not the commodity on how to approach this, but how to avoid having this almost impossible to trace bug.

This is the first time in my 5 years of elixir development when I literally had no idea what was going on, because after checking out on another branch (that was most probably when the cache was invalidated) the project was no longer working as expected, without any warnings, traces or ways to reproduce what happened.

Cool, I clearly misunderstood your intent.

I agree it’s a problem.