Awesome! That’s exactly what I was looking for, thanks for sharing @steffend.

btw there is work in progress to remove phx-no-feedback: https://github.com/phoenixframework/phoenix_live_view/pull/3090

The idea here is to only add the error classes server side if used_input?(field) returns true.

The point is that you can use semantic class names instead of hardcoding color names. My input component can support a infinite variety of color themes without modifying the CSS of the component. The specific library is irrelevant. daisyUI happens to have the ability to do this. You don’t have to use the library to utilize the technique.

Hi @arcanemachine, thanks for your contribution but this is unrelated to the problem I’m afraid .. The point has more to do with how feedback state is being handled on inputs than what styling library to use, so using a different class name or library doesn’t really address the concerns posted by @AHBruns. Cheers!

I used daisyUI for a couple projects a while back, and it uses a Bootstrap-esque naming scheme for its colors (which are also fully customizable). Instead of hardcoding colors like bg-zinc-500, you just specify bg-secondary. I found it to work pretty well, and it makes it trivial to add additional themes, or modify existing ones (just change the color definitions in the tailwind.config.js file).

Component demos: Component Showcase - Quiz Game (You can change the theme by clicking the gear icon in the top-right corner.)

GitHub code:

• Components: phoenix-quiz-game/lib/quiz_game_web/core/components.ex at master · arcanemachine/phoenix-quiz-game · GitHub

• Tailwind config: phoenix-quiz-game/assets/tailwind.config.cjs at master · arcanemachine/phoenix-quiz-game · GitHub

I wonder if there are any initiatives to improve this, I was revisiting some old code that uses core components today and noticed that we redeclare classes for the base styles of an input (notice the border-zinc-300 and focus:border-zinc-400):

 "mt-2 block w-full rounded-lg text-zinc-900 focus:ring-0 sm:text-sm sm:leading-6",
 "phx-no-feedback:border-zinc-300 phx-no-feedback:focus:border-zinc-400",
 @errors == [] && "border-zinc-300 focus:border-zinc-400",
 @errors != [] && "border-rose-400 focus:border-rose-400"

PS.: If you follow this pattern, once you have to support a dark mode (or responsive variants) which is what I’m doing now, you start having lots and lots of duplicated classes.

I think it is an alternative to surface UI with steroids attached.

Write all your UI in one file, html, state, JS, and styles.

Oh and animations too!

Ditch the hooks and things like alpine.js and just use the disappearing Svelte framework which complies to just your code. It’s very tight.

Seems like the killer combo to me.

The only thing I can see is if you decide you want some pages with svelte elements to do sever side rendering you will need to ship with the renderer like node/bun, but that is 100% optional, svelte is progressive.

This is really interesting. Especially from the point of view of page-specific javascript. Can this be an alternative to using phoenix hooks?

The tailwind philosophy is exactly that though, use ulitity classes to do exactly what you want where you need it.

I think ultimately there needs to be a layer where you have enough composability or a theming layer where you can override the classes/theme and define variants for your particular app or site on top of that base layer. So once you define the variants your app would be built using the components and your defined variants with no class passdown.

I was also looking at liveview+svelte as a possible way forward to get better access to a broader set of UI components and a much richer UI given liveview hasn’t got there yet.

It’s kinda mind blowing what @woutdp has done with the ~V sigil to merge svelte and liveview. I am surprised this hasn’t got more attention:

I didn’t get the impression that you are someone who is easily offended Also, it’s always weird when I have a notification from andrewh because I’m Andrew H

Ya, I think the whole idea of CoreComponents just isn’t clear. My understanding of them is that they are not designed being part of a UI toolkit but as part of an app-specific constraint-based design system. For the latter, I believe being able to pass classes in for customization is a big anti-pattern—Your app’s design system should have ready-made components for different scenarios as opposed to a UI kit which you use to build said design system. I think it’s ok to have some wrapper components that take attributes for spacing, which is to say I do agree that including margins in components is a bad idea. But this was part of my elusive “this is what frustrates me about the web dev world” comment. I think that’s something people are just never going to agree on, so it’s hard to have a generated default that will please everyone.

I agree we need this but I’m not sure it should come from the core team. There needs to be a business who is all-in on LiveView who can get behind this type of thing. Unfortunately, as has been touched on in this thread, the likelihood of that is iffy. Most job postings I see are for Phoenix backend with React/other frontend. Even if LiveView is used I still see React being mentioned (which I’m assuming means they are using LiveView for their admin area and React for their app?) I think there just aren’t enough frontend people who focus on the “HTML-over-the-wire” stack since there are no jobs in general. I tried to sell myself as such last year when looking for a new job and of course was horribly unsuccessful

Proofing this I realize I’m writing with a tone as if everything I’m saying is fact—this is not the case.