Yeah, I think it would be better not to add more dependencies. But some components are really hard to implement without using custom JS, so I have to skip them at this time.
I’ve already added select component. It doesn’t behave the same with built-in select, but it looks better ha.
There are lots of challenge to implement client side select with LiveView.
You really shouldn’t try to avoid it, it’s there for a reason and I think it would be the perfect addition to this project. I’d recommend having a look at whatb melt-ui does for svelte components.
I wonder if that library could be used as a dev dependency, compiled and integrated into hooks akin to LiveSvelte, like a light-weight version of what shadcn-svelte does…
I’d like to help explore this when I have some spare cycles, if you don’t get to it first
I would definitely agree that shipping some hooks for necessary interactivity is reasonable. Good impulse to first try getting on without, but some components are likely trivial with a hook but convoluted or impossible without it.
I haven’t tried shipping a component with an integrated hook for others to use. I suppose you need to decide if that JS is a per-component import for app.js or figure out something smoother?
There are ways to load them dynamically as needed while hinting to the browser to prefetch and cache for performance gains. Basically a combination of promise-based import() and <script type="importmap"></script>
I’ll see about creating a PoC soon.
Anything ARIA-related is a prime candidate. Liveview has an implementation of this for wrapping tab focus on things like dropdown menus