CVA - easily construct component variants

Your Libraries & OS Mentoring Libraries
,
1

ex_cva
ex_cva1200×600 26.5 KB

I created a new library GitHub - benvp/ex_cva: Class Variance Authority for Elixir which aims to make it very easy to define different variations of function components. I experimented and tweeted about it a bit and I really like how the api is looking now.

This library is heavily inspired by the amazing work of Joe Bell on GitHub - joe-bell/cva: Class Variance Authority in the JS world. The approach reasonates so much with me, that I wanted to have something similar in the elixir world.

What do you guys think?

11 Likes
2

I just had a quick look at the readme, but wanted to leave a thank you for retaining the simple functional API. Macros are great, but I’d be worried wrapping Phoenix.Component that things will break with future liveview versions, but I can see myself using the plain API.

4 Likes
3

I separated the both apis because they are building upon each other. So the core logic is just constructing the proper class names and the declarative api is build upon it to make it a little more convenient.

I understand that something potentially could break on new LiveView versions but I’d argue that the risk is quite low. The macro based approach essentially

  • creates a few module attributes to keep track of the cva related configs/state.
  • generating Phoenix.Component.attr/3 calls with values derived from the variant.
  • wrapping the function component and calling Phoenix.Component.assign/2. This is the same approach which LiveView does internally for declarative components.

I’m not touching LiveView internals and only use public apis.

Scenarios where it could potentially break:

  • Changes in the attr/3 api in a breaking manner.
  • The definition of HEEx function components is changed. Like requiring multiple arguments.

I think that’s both pretty unlikely. And even if it happens, as the cva macros api is very thin layer.

4

I just released version 0.1.2 of ex_cva and improved the docs a bit after receiving some feedback.

The version fixes an issue which would always apply class assigns if it was present, even if @class has not been explicitly passed into the component. This could end up in having duplicate classes if a component configures variants and accepts a class assign.

5

Thanks for the very nice library!

I’m curious how you recommend dealing with variants that arise from the presence of HTML attributes. For instance,

<button intent="secondary" disabled>
  hello
</button>

vs

<button intent="destructive" disabled>
  hello
</button>

should be styled differently.

In my example above, the original CVA lib seems to recommend making disabled another intent variant which I’ve done for now, but do you have advice for composing these more easily?

6

Thanks for bringing that up Jon. I found a few things in the library when using that approach.

In general I agree with the way the original CVA library recommends on handling things like disabled. Adding a new boolean variant if the way to go. Otherwise you could also add classes with the :disabled css pseudoclasses to style the button, when it’s disabled.

Starting with 0.2.0 of ex_cva you can do sth like the post recommended. Read below.

1 Like
7

I just release version 0.2.0 of ex_cva.

[v0.2.0] (2022-12-06)

Improvements

  • variant/2 now properly supports boolean values. You can now do something like the following:
variant :disabled,
        [true: "disabled-class", false: "enabled-class"],
        default: false
        
# or

variant :disabled,
        [true: "disabled-class"],
        default: nil
        
def button(assigns) do
  ~H"""
  <button class={@cva_class} disabled={@disabled}>
    <%= render_slot(@inner_block) %>
  </button>
  """
end
        
# ... where you use that component

<.button disabled>Click me</.button> 

# -> <button class="disabled-class" disabled>Click me</button>
3 Likes