In my project I’m also using LiveVue with shadcn-vue. It indeed works quite well and integrating it was a breeze, since Phoenix uses tailwind by default and LiveVue integrates Vite.
Thinking about your idea… it would require a fairly complex interop of LiveView / JavaScript, mostly when it comes to slots and nesting components. I’m not sure if it’s really possible, since vue components woul need to be rendered differently depending if it’s nested inside other component or not (to avoid creating multiple root-level components)
But maybe I shouldn’t write here since it’s not the topic for it I think integrating client side hooks is a necessity for good UX. Recently there was a quite huge drama on twitter how LiveViews doesn’t scale because of delay between interaction and change in UI in Hey application. This could be avoided with hooks. Just it’s quite challenging to write complex components using hooks because it’s imperative - you have to control all changes by yourself, there is no way to declare a template and ask library to keep it in sync with the state… that’s why I’ve created LiveVue
But all in all @bluzky you created something really neat, I’ll be using it in the future!
Thanks for sharing, I think javascript is required to implement something like combobox or command, … and I think it would be too complicated to implement with a pure LiveView approach.
As a backend developer(original actionscript and java dev…later php) I worked for many many many years with all javascript frameworks and I am so damn happy Liveview allows me to escape this with minimum javascript.
I am sick of all the brands I had to go through:
jquery, mootools for starters
then Backbonejs seemed to get hot, so I jumped that bandwagon,
then Angular 1 seemed to get hot, so I needed to jump on that…
then VueJS, EmberJS or ReactJS would become the leading framework…so I needed to pick for the first time. So I picked VueJS and ReactJS, after trying them both.
Man… I don’t even want to talk about all the bloatware that I had to learn/understand/remember/install just to build a javascript file.
…requirejs, babel, webpack, npm, npx, grunt, gulp, rollup, idk… ugh
TLDR: Svelte is also such a brand. Another framework, which one day will die out and all our bloated frontends will be infected with this decease. I really hope that we will not have to add anything except pure vanilla javascript…and even keep that to an absolute minimum.
If folks really want to Jabbascript, then folks can always build a SPA and keep the backend and frontend strictly separated and use whatever bloat javascript framework out there.
Thank you for this effort , this will make it easier for people coming from the backend side to do the frontend work and fulfill Elixir promise of one stack and one resource
Actually I believe going forward integrating with live components will be the preferred mechanism for many developers to build the frontend
In this case it’s weird to see every single element to have a prominent appearance on the page, bold powerful contrast in all borders, labels, text, etc.
The moment you switch to text input and text area? Invisible pale gray borders and text.
It’s not just shadcn and its re-implementations, mind you. Nearly every single CSS framework has the same issue.
The components look really great, thank you for making them available.
There are currently several parallel initiatives for the development of live components, which raises the question of where possible synergies might exist. For example, would it be possible to use Doggo as the basis for the SaladUI components? I don’t have enough experience myself to weigh up the pros and cons of this sufficiently.
Just a proper package.json and documentation for adding it as a dependency through the deps folder should be enough.
We use yarn with zero install which means we have no node_modules folder. If we can just point it at a package.json which would declare a default index.js or something then our yarn and esbuild would be able to bundle everything on our own and not have to worry about what versions you shipped and whether my esbuild was able to properly separate the versions. I’d have to go look at the index.js of the library to confirm that it’s not doing something weird to meet compliance requirements.
Or you could configure your own esbuild/bun minify. That would be an option for folks without a build pipeline, that want to just include a fully packaged js file
I think integrating client side hooks is a necessity for good UX. Recently there was a quite huge drama on twitter how LiveViews doesn’t scale because of delay between interaction and change in UI in Hey application. This could be avoided with hooks. Just it’s quite challenging to write complex components using hooks because it’s imperative - you have to control all changes by yourself, there is no way to declare a template and ask library to keep it in sync with the state… that’s why I’ve created LiveVue 
