The default button component generated by Phoenix generators looks something like this at class level: ... <button class={[ "phx-submit-loading:opacity-75 rounded-lg bg-zinc-900 hover:bg-zinc-700 py-2 px-3", "text-sm font-semibold leading-6 text-white active:text-white/80", @class ]…

Core components are part of your application. You can customize them however you need. E.g. you could introduce a higher level attribute :background, which maps or defaults to lower level classes. Concatinating strings of classnames doesn’t really offer any more help for additional semantics like th…

So it’s considered good practice to change these core components? Had this question for a while

Yes, otherwise they would be in a library not in your codebase. You can even remove them if you don’t intend to use the phoenix generators to generate html pages for you.

I agree with your point @LostKobrakai . The default core_components.ex functions like a starting point and inspiration I guess… A follow up question then. What libraries already exist for more fully fledged components ready to use as LiveView.Components? Currently I build my own components based on…

It’s a gap in the ecosystem… [image] Phoenix liveview UI(components) suggestions? Questions / Help There isn’t a viable component based UI package for pheonix. There is Phoenix UI but it embeds the style/theme so you’re left overiding classes everywhere, still it might be…

For any future reference and readers, I followed @LostKobrakai ’s advice and started extending the default <.button /> component. It is pretty easy (and fun) to do. Take not it is still very much a WIP attr :type, :string, default: nil attr :variant, :atom, values: ~w(contained outlined text)a,…

Button from core_components struggles with class precedence

Questions & Help Questions

adw632 November 16, 2023, 12:57pm 6

It’s a gap in the ecosystem…