D4no0

D4no0

On a more general note, I think that is not very smart to scan for classes in source code, especially since elixir has metaprogramming. In theory it would be possible to scan for dynamic classes throughout the phoenix compiled templates and detect specifically a couple of things:

  1. Compute dynamic strings that can be resolved at compile-time (macros);
  2. Deliver warnings to user (this can be done by a separate system, however it would be nice if integrated);
  3. Have less content to scan (handling only compiled templates to tailwind, it doesn’t need to scan entire codebase blindly).

@zachdaniel it would be great to know what your opinion is and what the Tails library was aimed to solve, and if it can be used to create some of these features.

0
Post #11
zachdaniel

zachdaniel

Creator of Ash

Yep! We shouldn’t scan source code, we should provide a macro or sigil that does the validation. The tails library solves for class merging and conditional classes. Class merging is necessary for allowing components to have their classes overridden by parents passing down classes(my preferred way of overriding components) and tails will do a semantic merge based on what classes “conflict” in tailwind.

I’m already working on a macro version of classes as well as a sigil. The macro version will, for now, warn on interpolation unless possible values for the interpolated expression is provided.

3
Post #12
D4no0

D4no0

I was thinking on a opt-out way to do this, because my thinking is that new people coming to the ecosystem will have the most trouble not doing this mistake, moreover sane default options always beat optionals.

This, of course implies a conceptually different approach, however I think that would be possible if you would add it as an compiler in mix after elixir. I’m not sure about limitations or performance penalty on this, you should know this much better than me.

Do you think the sigil opt-in approach is more friendly?

0
Post #13
zachdaniel

zachdaniel

Creator of Ash

Well, I’d love for it to be doable in phoenix directly, I even made a PR that would allow configuring a handler for all class properties, but it was rejected(no hard feelings). I use tails everywhere anyway :joy: . I do see that it kind of defeats the real goal of helping people avoid the footgun. A custom compiler could work. It would be…pretty difficult though. Likely filled with false negatives or false positives depending on the implementation.

1
Post #14
D4no0

D4no0

Maybe that would be possible in the future, I have a feeling that heex will evolve to the point that it will fully parse and understand the html, at least that seems the direction it is taking.

This is what I was afraid to hear, going into internal implementation details of phoenix (especially as a separated library) would be the same as shooting yourself in the foot, more potential problems than gain.

0
Post #15
zachdaniel

zachdaniel

Creator of Ash

Okay, decided I don’t actually have time to do the thing I wanted :laughing: but PRs welcome if someone wants it. I did manage to add a sigil that should clean things up.

1
Post #16
m-collins

m-collins

We’ve had some really nice wins in this space by moving to using tailwind in conjunction css variables and data attributes.

This video is a good summary

We use it for a heap of different use cases. themes (dark, light, high-contrast etc) , status (warning, success, danger, info), surfaces (standard, faint, inverse), categorical charts colours etc. CSS variables are amazing and really under rated.

Once in place you end up with much cleaners views.

No more dark:text-white

No more explicit class definitions

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

If you adapt the fundamentals in that video, you’ll end up with something that looks like this:

<body data-theme={@theme} class="text-standard bg-standard">
    <div data-status={@status} class="bg-status text-status">
      <% @status.message %>
    </div>  
</body>

It also responds to any changes on the client. E.g. switching a data-theme from light to dark. You can even take this much further by allowing users to configure their own theme within the app and then assigning those values to your css variables. We haven’t tried this, but it’s certainly possible.

There’s a bit of upfront work to put your design system in place, but the flow on benefits have been huge for us.

0
Post #17
— All posts loaded —