Inspired by the today exchange with @josevalim regarding a particular maybe-LiveView-maybe-Alpine bug (see the links below) I’d like to open a discussion on the best way to proceed in future cases like this.
I agree with Jose’ that PETAL (LiveView+Alpine) users should have a single point of reference such as a single repository with just a README.md file where we could merge our knowledge base and best practices, a place that unlike various blogs around will have a history.
Does anyone know if such a repo exists already? If not, I can go about creating one.
In addition, maybe @AstonJ can make a special PETAL sub-category under Phoenix Forum.
Delighted to see so much interest (3 likes so far)! </sarc>
Anyway, the LiveView-Alpine github organization and its integration knowledge-base repo can be found at the link below. It’s currently empty but I (we) will be adding content as we go.
I went the Alpine route when LiveView was new and without any JS integration outside of Hooks, for micro interactions Alpine made so much sense (and I was familiar with Vue API which Alpine kinda of mimics).
I later dropped it in favour of just plain LiveView.JS usage and/or combined with Hooks.
Why? Well, because of the CSP (Content-Security Policy), reference: CSP — Alpine.js
In order for Alpine to be able to execute plain strings from HTML attributes as JavaScript expressions, for example x-on:click="console.log()" , it needs to rely on utilities that violate the “unsafe-eval” content security policy.
I’m not comfortable with the trade back nor with the CSP violation, so I preferred to go the %JS{} / Hook routes.
Glad for your contribution, think that is a good idea. The Phoenix components PETAL framework makes use of Alpine, maybe it can also serve as inspiration for people following that route.
I get where you’re coming from, but I really don’t see how you can contrast Phoenix.LiveView.JS + LV hooks to Alpine.
Hooks can be helpful for achieving the kind of client-side behavior that is triggered by the hook events. Beyond that (i.e. trying to manage complex state with them) it’s becoming an overkill. I know because I did plenty of that (3 - 4 years ago) before I started using Alpine.
The JS module merely covers some very basic needs and cannot possibly replace the wide spectrum of Alpine application.
You are right, %JS can’t replace Alpine at all, and probably it never will. That is why we have hooks. I dont think hooks are overkill at all, simply a necessity and generally sprinkling some hooks are all we need in LV land. When hooks get co-located I think we really wont need Alpine at all.
But Alpine is very practical indeed inspite of the CSP violation.
Collocation will help organize them better, but it won’t solve what can and what can’t be done easily with them, that’s unless you find it acceptable to have more JS code then the template code with the hooks merely adding and removing the listeners which then invoke the JS code, for that’s the only way you can replace Alpine, all while reinventing the wheel over and again.
Speaking of which, have you tried replacing any of the following with the hooks (never mind not being “collocated”):
x-model + x-effect
x-timeago
x-intersect
I did some of those and, boy, do I not want to do stuff like that again with hooks.
Alpine is very practical, indeed. I’d compare it’s practicality relative to writing hooks as using tailwind relative to maintaining separate CSS/SCSS files.
I found managing compex state in Alpine a bit of a mess and moved to JS commands and hooks too. The interaction between a hook and liveview’s lifecycle is much easier to manage than liveview and alpine.
I never used the x- thingos you mentioned though. Not sure they were around back then.
There are some people reporting issues with using Alpine, but more often than not those originate from their lack of understanding how to do things correctly (hence this ongoing effort). Also, I have 0 issues with Alpine (except for performance issues) while working on a relatively large and very granular app (in terms of both LiveComponents and function components).
As for the x-thingos, what can I say, the requirements I got are quite demanding on the UX but admittedly not all apps may have such a case.
