I don’t want conversations about Tails to be a distraction from your announcement, but I very much appreciate your taking the time to check it out and highlight some issues. What you’re doing with component accessibility is far more than the scope of Tails and is very very cool! 
zachdaniel
Creator of Ash
1
zachdaniel
Creator of Ash
I’ve soft-deprecated tails, primarily based on the issues your tests pointed out, and point folks at turboprop instead 
I spent ~2 hours fixing it, and got some of the issues addressed, before I remembered that I maintain like 50 packages at this point and I just don’t realistically have the time to actually fix tails
6
cschmatzler
I like cva, also in the JavaScript world, but it doesn’t offer slots and by extension compound slots, or easy overrides, so I haven’t found it powerful enough to build a full design system.
0
benlime
cva creator (or person who ported it to elixir) here. Can you elaborate a bit on whats missing for you? i’m not sure I fully understand it and if it’s something how cva could be extended to.
0
cschmatzler
Heya!
What I’m missing is the ability to define component variants that span multiple HTML elements - and by extension with compound slots, the ability to define multiple similar but distinct elements without repetition.
For example, something like this:
defmodule Pagination
import Turboprop.Variants
@variants %{
slots: %{
base: "flex flex-wrap relative gap-1 max-w-fit",
item: "data-[active]:bg-blue-500 data-[active]:text-white"
},
variants: %{},
default_variants: [
size: "sm"
],
compound_slots: [
%{
slots: [:item, :prev, :next],
class: [
"flex flex-wrap px-2 py-1 truncate box-border outline-none items-center justify-center bg-neutral-100 hover:bg-neutral-200 active:bg-neutral-300 text-neutral-500"
]
},
%{slots: [:item, :prev, :next], size: "xs", class: "w-7 h-7 text-xs"},
%{slots: [:item, :prev, :next], size: "sm", class: "w-8 h-8 text-sm"},
%{slots: [:item, :prev, :next], size: "md", class: "w-9 h-9 text-base"}
]
}
def render(assigns) do
assigns = assign(assigns, :variants, @variants)
~H"""
<ul aria-label="pagination navigation" class={variant(@variants, slot: :base)}>
<li aria-label="Go to previous page" class={variant(@variants, slot: :prev)} role="button"><</li>
<li aria-label="Page 1" class={variant(@variants, slot: :item)} role="button">1</li>
<li aria-label="Page 2" class={variant(@variants, slot: :item)} role="button">2</li>
<li aria-label="Page 3" class={variant(@variants, slot: :item)} data-active role="button">3</li>
<li aria-label="Page 4" class={variant(@variants, slot: :item)} role="button">4</li>
<li aria-label="Page 5" class={variant(@variants, slot: :item)} role="button">5</li>
<li aria-hidden="true" class={variant(@variants, slot: :item)} role="button">...</li>
<li aria-label="page 10" class={variant(@variants, slot: :item)} role="button">10</li>
<li aria-label="Go to next page" class={variant(@variants, slot: :next)} role="button">></li>
</ul>
"""
end
end
We have a pagination component that has a list of pages, a back/forward button, and different sizes for the buttons available. The page buttons should respect active state, which is the only differentiator from the back/forward buttons, which obviously don’t have active state. Something like this is really difficult to build with CVA.
On top of that, overrides. So this is our variants, but design comes along and wants a slightly different pagination on the help center page. It’s a one-off.
def render(assigns) do
assigns = assign(assigns, :variants, @variants)
~H"""
<ul aria-label="pagination navigation" class={variant(@variants, slot: :base, class: "gap-2")}>
...
</ul>
"""
end
This is not supported by CVA. Just adding class="gap-2" on the ul element itself does not necessarily work because it’s a conflict with the existing gap-1 and application depends on the order in which Tailwind defines the stylesheet. Since Turboprop implictly tosses its entire output to merge/1, this gets resolved for us.
I still think CVA is great, though. If this kind of functionality isn’t what you need, by all means, use it! If you’re already using it and haven’t ran into limitations, don’t change to something else. Having options is always great, and it doesn’t always have to be a competition
0
Flo0807
cschmatzler
Actually had already started working on it 
this is a bit of a difficult one to keep working across LiveView updates (in this case I’m doing the search on the server and actually streaming in new countries), so it’ll need some love before I’ll push it.
https://x.com/cschmatzler/status/1803044703245398130
1
ivanminutillo
An accessible component library for phoenix/liveview built with turpoprop sounds rad. We’re currently using daisyui (a component library built on tailwind) in combination with Surface, but we end up manually writing the hooks for almost all the client interactions (which includes standard interactions like a modal, popup, accordion, tabs, wyswyg editor, emoji menu, popover, etc.) that we use across our application ( bonfire - a federated social network )
We’d love to contribute to this effort somehow!
0
cschmatzler
Surprise!
0.4 contains a ton of breaking changes (again, still playing around and experimenting a lot so don’t use this in a real project just yet), but also Accordion and Combobox components and a change to TypeScript which is nice I guess.
Take it for a rest ride and let me know if anything smells!
3