6 ms·
I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to re
by sb8244 3y ago
I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to rebuild it yourself. It takes a lot of time.
What I ended up doing was loading react components using LiveView hooks and syncing state using pushed events. Saved me a ton of time because libraries were all there, and worked seamlessly alongside my LiveView app.
- impulser_ 3y agoThere are component libaries for LiveView. https://github.com/petalframework/petal_components https://github.com/petalframework/petal_components https://github.com/coingaming/moon https://github.com/coingaming/moon I personally wouldn't use React for components in LiveView, you are just adding more complexity to your application for no reason. It really not that hard to build components using JS and LiveView. In the end you get less complex components than what you would get with react.
- ahallock 3y agoThanks. I took a cursory look and they just don't seem as high quality as something like shadcn/ui (built on Radix UI) or Tailwind's upcoming Catalyst. For example, on Moon, the dropdown arrow support seems broken and it doesn't switch positions based on the viewport. It's these little details that matter, especially for accessibility.
- sb8244 3y agoWhat about wysiwyg editors? Something equivalent to react-grid-layout? Date pickers? I want to build a startup, not rebuild complex components for the sake of purity. Simple components are taken care of, but I think that's not where the discussion is very relevant. I'm sorry to disagree here, but I think it's disingenuous to act like the problem is solved when there's really quite a large gap. (Btw, of course I built my components with pure LiveView when it made sense.)
- sodapopcan 3y agoI always find good vanilla JS for everything I've needed (though my needs haven't been too special). Depending on what you're building you could also say: "I want to spend time building my business, not writing an API for myself just so I can communicate with my own backend." Which is not even to mention how much simpler concurrency features are. But again, it depends on the application.
- sb8244 3y agoTrue, I used a vanilla wysiwyg editor integrated via hooks. To be clear, I heartily endorse LiveView. Not using it now due to pretty heavy chrome extension needs, but it was solid. It's just rough in the "just works JS integrations" department. I'd argue you have to be really good at JS to handle any heavier library integrations.
- sodapopcan 3y ago> I'd argue you have to be really good at JS to handle any heavier library integrations. You aren't wrong there! LiveView was initially developed to make a certain class of web-app without needing JS. Of course, people went and pushed it further and I see it as a "only write the JS that is necessary" type of framework. I'm very fullstack-minded so this doesn't bother me in the least. I love writing JS for DOM manipulations and whatnot, I just don't want to write any business or server-side logic with it, so LiveView is a great fit for me. But even as an advocate, if your application needs to be very JS-heavy, I wouldn't necessarily recommend it. No frameworks are one-size-fits all, but of course most people want to work that way.