Utility classes are 2022 - now we have utility elements

[Sebb]

is this too evil?

<.flex gap-4 justify-start>
  ...
</.flex>

<.grid grid-cols-3 gap-3>
...
</.grid>

defmodule Components.Tailwind do
  use Phoenix.Component
  import Phoenix.LiveView.HTMLEngine, only: [component: 3]

  def flex(assigns), do: component(&div/1, classes(assigns, "flex"), [])
  def grid(assigns), do: component(&div/1, classes(assigns, "grid"), [])
  ...

  defp div(assigns) do
    ~H"""
    <div class={@classes}>
      <%= render_slot(@inner_block) %>
    </div>
    """
  end

  defp classes(assigns, base) do
    classes =
      assigns
      |> Enum.reject(fn {k, v} -> k == :__changed__ || v != true end)
      |> Enum.map(fn {k, _} -> k end)
      |> Enum.join(" ")

    assign_new(assigns, :classes, fn -> base <> " " <> classes end)
  end
end

[sodapopcan]

Can’t say I haven’t thought of it more than a few times

I was thinking along the lines of more of a “styled components” approach like grid="cols-2 justify-end gap-2" and so on, but ultimately decided “nah”. But then again… maybe.

EDIT

Oh wait, I missed <.grid which yes, that’s far more of a styled components approach.

[BartOtten]

Please also create SubSubSubSubHeader

@BartOtten

This section makes me laugh. Can’t help it but it seems utterly clumsy.

• For React 3 components are created: Header, SubHeader and SubSubHeader. The next example uses a plain JS function named title to return a list of ultility classes. Let’s apply those to H6: SubSubSubSubSubHeader and subSubSubSubSubTitle()! Guess we are back at “naming things is hard”.

Evil or not; it looks in the spirit of Tailwind

[sodapopcan]

The company I used to work for does have a design system in React that is very close, though a lot of the “values” took their own values (like for example). It’s based off of styled system.

I think accepting any bare attribute as a class is pretty iffy. I was thinking this could better suited to more of explicitly defining what attributes are style attributes. A few special ones could have their own components too, like in your example:

<.flex justify="center" items="center" gap={4} />
<.img rendering="pixelated" />

…and then of course you’d have to have <.box> or something for <div>s. I guess really you would need a componentized version of most or maybe all dom elements (though slots could get rid of a bunch of them probably).

Anyway, then the values could just map to tailwind classes, or possibly even another CSS framework’s classes.

Anyway, I’m just thinking out loud as I have thought quite a bit about it in the past but it’s been a while, so sorry if I’m not being clear or even making any sense.

[LostKobrakai]

I’d suggest taking a step back and ask yourself if changing the syntax for how to apply css is actually useful. In my opinion there’s not much use in that. I’d rather look into actual higher levels of abstraction, like e.g. presented on https://every-layout.dev/.

Also I’d worry there’s pitfalls for LVs change tracking with the approach you’re taking there.

[Sebb]

@sodapopcan

grid=“cols-2 justify-end gap-2”

Do not quite get what the difference to class="cols-2 justify-end gap-2" is here…?

@sodapopcan

The company I used to work for does have a design system

that looks funky!

@sodapopcan

I think accepting any bare attribute as a class is pretty iffy. I was thinking this could better suited to more of explicitly defining what attributes are style attributes. A few special ones could have their own components too, like in your example

Yeah though about that. But I’d need way more experience to find right attributes, in my brutal approach there is no need for this.

@LostKobrakai

I’d suggest taking a step back and ask yourself if changing the syntax for how to apply css is actually useful. In my opinion there’s not much use in that.

The main reason I did that in the first place was because I can. But then I noticed that I like it.
It brings a little order in the tailwind stew (loving tailwind! but still…) without losing any of its flexibility. (For more involved classes that are not valid attribute-names one could add an explicit class attr).

@LostKobrakai

I’d rather look into actual higher levels of abstraction, like e.g. presented on https://every-layout.dev/ .

Will do.

@LostKobrakai

Also I’d worry there’s pitfalls for LVs change tracking with the approach you’re taking there.

I was bitten by that some time ago and thought I understood whats going on, can’t see what would be the problem here…!?

[sodapopcan]

@Sebb

Do not quite get what the difference to class="cols-2 justify-end gap-2" is here…?

I basically just mis-remembered and responded too quickly and tried to cover it up I meant the <.grid cols={2} ... /> approach.

[LostKobrakai]

@Sebb

I was bitten by that some time ago and thought I understood whats going on, can’t see what would be the problem here…!?

import Phoenix.LiveView.HTMLEngine, only: [component: 3]

Maybe not for change tracking, but afaik using this essentially means the LV has no means of splitting the static content of a template from the dynamic parts, which is used to optimize diffs by not sending the static parts again.

[sodapopcan]

@Sebb

It brings a little order in the tailwind stew

I think the crux of why I didn’t dive into even really trying this is because we shouldn’t really be repeating ourselves with Tailwind. The “messiness” of Tailwind is usually relegated to single components (and can be organized by type over multiple lines). I try to have as few Tailwind classes as I can in LiveViews or dead view files, so getting rid of the class attribute didn’t feel like a giant win.

[LostKobrakai]

@LostKobrakai

Maybe not for change tracking, but afaik using this essentially means the LV has no means of splitting the static content of a template from the dynamic parts, which is used to optimize diffs by not sending the static parts again.

Thinking about this some more I might actually be wrong here. This static vs dynamic part is likely done at runtime, where using the a dynamic component wouldn’t really be different to a compile time known one.