Tails - Tailwind & Tailwind Component Utilities

Your Libraries & OS Mentoring Libraries
,
1

Making components take tailwind classes is a dicey proposition at best. You can’t just put a set of tailwind classes after another set and expect them to do the right thing, because later classes in the class string don’t override earlier ones, its all based on how “specific” the CSS that class applies. In looking for an example, I found a similar package for js that illustrates the need for it: https://www.npmjs.com/package/tailwind-merge.

I’m (slowly) building a set of utilities to help make more “tailwind-y” components, and also to be able to leverage tailwind in other ways. This library isn’t published to hex yet because it will need some more love, specifically it needs a lot more merge logic. It currently only handles some basic things.

Eventually, I could also see it supporting other kinds of directives to help overriding what a component does. For example, if a component sets something like bg-blue-500 hover:bg-blue-600, but you want it to use bg-red-500 always we could support something like <Component class="all_directives:bg-red-500" />. Or if you wanted to remove a class that the component adds, you could do so with <Component class="remove_class:bg-blue-500" />.

The ideas above are dubious, not sure if they are a good idea, but the point is that the potential for them is there :slight_smile: The part I am sure of is that having a class merger will allow us to write better components that can take tailwind classes and use them as overrides for their own classes.

It also handles merging a list, as well as conditional classes and nested lists, so in the end you might have something like this:

class={classes([
  "inline-flex items-center justify-center gap-2 text-sm font-medium font-sans transition-colors duration-300 disabled:cursor-not-allowed flex-grow-0",
  handle_button_hierarchy(@hierarchy), 
  handle_button_size(@size, @show_label),
  [
    "flex-row-reverse": slot_position == "trailing",
    "w-full": @expanded
  ],
  @class
])}

The other thing it currently does is defines functions that map to your tailwind colors, if configured with a tailwind.colors.json file to use. For those trying out LiveViewNative, this means you can reuse any custom tailwind colors, i.e <text color={primary_light_600()}>{@text}</text>. We could perhaps find other ways to make tailwind the “source of truth” that can be shared between web and LiveViewNative?

Curious to hear your thoughts! If we can get a few more people interested to help build out the class merging rules, and especially if we can make it more integrated with the tailwind config, that kind of thing.

4 Likes
2

Sounds definitely like something that could be useful. By the way, some of your ideas reminded me of this library: GitHub - cblavier/phx_component_helpers: Extensible Phoenix liveview components, without boilerplate
which comes with utilities to manipulate CSS classes. Don’t know how similar they are to what you have in mind.

3 Likes
3

That does look very similar! My only qualm that I can see is that its just doing “prefix replacements”, which won’t work for things like block and hidden, and other tailwind specific things. But I do wonder if perhaps tails should just live inside of a tool like that :slight_smile: So they could say extend_class(..., tailwind: true)?

3 Likes
4

We actually no longer do prefix-based replacement in phx_component_helpers :slight_smile:

extend_class instead switched to a declarative mode where you can use a bang❗️operator to remove default classes, such as:

<.button class="!m-* m-12 !hidden block"/>

to override default margin and display properties.

I once opened a topic on this specific issue here: Need help with an issue on my phx_component_helpers library

5

stupid question: how does this work at all? Doesn’t the tailwind compiler just deliver the CSS for the classes it sees at buildtime? So when the only tailwind class in my templates is text-sm and I dynamically add text-xl how can the tailwind compiler know about that…?

2 Likes
6

The tailwind CLI will only scan your source code to see what CSS classes should be bundled in the output css.

So the only risk is to get, in your bundled CSS, classes that you actually won’t use because they have been dynamically excluded.

(I replied for my own lib I didn’t looked into Tails)

1 Like
7

So it does not parse the HTML and looks in @class but just looks for the classes as text in all files?

What about

size = "xl"
class = "text-#{size}"

can’t work, right?

2 Likes
8

You’re right it can’t work. You should never use String concatenation with tailwind

1 Like
9

No that doesn’t work. See Content Configuration - Tailwind CSS

3 Likes
10

yeah, for me personally the ! operator isn’t a great solution because the consumer of the component has to know about more than it necessarily should. I.e with tails

# in this example the component provides `pb-1`
classes(["p-4", "pb-1"])
"px-4 pt-4 pb-1"

But with the prefixed removal method

# gotta thnk, which class do I want to remove from the child, and how to I reapply the "parts" that I care about
<component class="!p-4 px-4 pt-4 pb-1" />

Separately from that, the exclamation mark actually has meaning in tailwind. Granted, its meaning is to basically do what you’re saying so that might not matter?

1 Like