note to self: never use livewire on client sites. Maybe for personal new sites is okay but don't throw it on legacy stuff. You will get white hairs
•
Back
Try creating one Livewire component per page and using alpine/blade components everywhere else. I use traits when pages have the same elements. Otherwise you'll run into problems with events and slots.
•
yes this is my experience too, more or less. In this other pinkary thread I described it better alpha.coz.jp/X3mdRb but in the end the php driven reactivity is not solid enough yet, but it has potential for the future.
•
In response to @danielpetrica
This really needs to be a whole blog post:
Livewire is solid but not a replacement for JS frameworks.
The idea is most apps don't need a JS framework because the content needs to be SEO and interactions ought to trigger a network request. Just use a powerful server framework and something simple like jQuery or Alpine for interactivity.
Livewire is better described as a protocol like Inertia. All you have to do is type in a method name and Livewire will serialize data and invoke the PHP function for you. (The protocol works by defining server components)
In Inertia, it's less straightforward, but serialization is in the hands the developer. This makes Inertia more compatible across tech stacks than Livewire, and this means you can have SSR for an existing JS frontend.
For me it was about finding Livewire's purpose. Now that I understand when to use multiple server components (and that Inertia is limited in this area), Livewire has been able to handle every feature I can think of.
•
I know how data should be saved in livewire but In my case it didn't work because I was probably using it wrong. Overall this is my limited experience with the tool. my other other side projects that I built from scratch are built on livewire and they just work. like adventcalendar.tech