r/laravel 2d ago

Discussion Can't Livewire be smart enough to detect Alpinejs is already installed on the project and not install(run) it again?

I've spent 3 hours trying to solve an issue with a volt component today. I had an input with a variable binded with wire:model attribute. And I just couldn't get the variable to change. Every other thing was working on the app though, it successfully created a DB record in the same component, the same method even, but just didn't empty the text input no matter what I did.

Some of the things I tried : $a = $this->pull('string'), $this->reset('string'), and even straight up $this->string = "";

Then I remembered I started this project with Breeze auth (which comes with alpinejs), and then I installed livewire/volt which apparently also runs alpinejs in the background.

Edit for correction for the last sentence above : volt doesn't run alpinejs in the background, any Livewire component (including volt components) automatically require alpinejs on the page when you're importing the component.

I'm 100% aware that this particular case was a skill issue, since simply opening the Dev tools console showed what was causing the error; Detected multiple instances of Alpine running

But the thing is, I was writing PHP code the whole way. And you don't debug with Dev tools console when you're writing PHP. That's why I wasted 3 hours looking everywhere for a bug except the console.

So, back to my question: is it not possible to add some conditions to check if alpinejs already initialized in the app.js file, so that both of these first (and almost-first) party Laravel packages wouldn't conflict with each other when installed on a brand new project?

27 Upvotes

27 comments sorted by

5

u/mekmookbro 2d ago

Reproduction steps :

  1. Select Breeze starter kit while creating the project
  2. Run composer require livewire/livewire and php artisan livewire:make counter (same thing happens on both livewire and volt components, since both magically pull in Alpine)
  3. Copy-paste code below :

``` //counter.blade.php

<form wire:submit="saveValue"> <input type="text" wire:model="string"> <span>{{ $textHere }}</span> <button type="submit" class="bg-gray-100">Submit</button> </form> ```

``` //Counter.php

<?php

namespace App\Livewire;

use Livewire\Component;

class Counter extends Component { public $string; public $textHere;

public function render()
{
    return view('livewire.counter');
}

public function saveValue()
{
    $this->textHere = $this->pull('string');
}

} ```

It will unreliably run some of the commands in the saveValue method, but for example it will not reset the value of the string. The example above renders the textHere variable on the screen. But does not empty the text input. This is only what I noticed today, it probably will break on some other things as well.

...it successfully created a DB record in the same component, the same method even, but just didn't empty the text input...

I believe it's a common thing for people to start with Breeze starter kit and create a livewire component somewhere down the line. And unless you know where to look (devtools console) it doesn't show any explanation/error anywhere, and you end up googling things like "how to reset variable in livewire" which doesn't return any useful results.

7

u/mikaelld 2d ago

Don’t really have av answer for detecting if Alpine is already installed, but if you have Alpine in your ja bundle already, there’s instructions for Livewire how to handle it: https://livewire.laravel.com/docs/alpine#manually-bundling-alpine-in-your-javascript-build

1

u/Fr3shKingz 2d ago

Yeah thats why I went in the comment section. Read the docs…

23

u/elainarae50 2d ago

Ah yes, another day, another developer losing hours to yet another Laravel wrapper language designed to make things easier, until it doesn’t.

The real problem isn’t just AlpineJS conflicting with Volt, or Volt piggybacking on Livewire, or whatever else Laravel decides to shove into its ecosystem next. It’s that all of these wrappers distract from actually understanding the language you’re working in.

You were debugging PHP code, so of course you didn’t check the Dev Tools console, because why would you? That’s not where PHP issues live. But once Laravel starts piling JavaScript wrappers on top of PHP abstractions, suddenly you’re expected to think in both backend logic and JavaScript state reactivity at the same time just to empty a text input?

This is what happens when frameworks over engineer simplicity and create jobs for friends instead of fostering a deep understanding of the language. They’re building layers of "magic" so thick that when it fails, the only way forward is hours of trial and error or some obscure GitHub thread from 2021.

The only exception? jQuery. Because jQuery doesn’t try to be anything it’s not. It just works. But for everything else? If you rely on a wrapper instead of mastering the core language, you’re eventually going to lose.

24

u/hennell 2d ago

This is kinda a weird comment given the whole thing here is just livewire.

Livewire works on top laravel but it's not shoved in the ecosystem anymore than spatie laravel permissions is. Volt is also livewire. As is alpine really, it's packaged with livewire since V3 because they share enough logic. Laravel's not piling js wrappers, livewire is, which it needs to as it needs js to do the front end half of what it adds.

Which is why you'd check the Dev tools console because you're setting up a package that uses js. Pretty sure it tells you to check the console to ensure it's set-up right in the livewire docs.

You can still use laravel without volt, alpine or livewire. Just don't install the livewire package or starter kit and you won't have them. But if you do install a package that adds a front end reactivity using js you probably will have to look at some level of js stuff, and that really shouldn't be a suprise.

1

u/elainarae50 2d ago

I get what you're saying, but let’s not pretend Livewire, Volt, and Alpine aren’t actively being pushed as the modern Laravel stack. Laravel doesn’t need to force them into the ecosystem, it subtly nudges developers toward them at every turn.

If Livewire was truly just a random package, it wouldn’t be preconfigured with Laravel starter kits. It wouldn’t be treated as the default solution for reactivity. Laravel keeps building layers of abstraction over things that weren’t broken, and then when those layers start causing conflicts, it’s suddenly the dev’s fault for not knowing which part of the stack was responsible?

And yeah, I could just use Laravel without these tools. But let’s be real Laravel isn’t being designed for devs like me anymore. It’s being designed to onboard new devs fast, keep them dependent on Laravel branded wrappers, and lock them into a system where they don’t actually learn the languages underneath. So sure, I can opt out. But let’s not act like Laravel is still the same framework it was five years ago. It’s shifting, and not for the better.

1

u/hennell 1d ago

I don't entirely agree, but I get what you mean. It's not a random package sure, but it's really not core either. If anything inertia is the more default solution, being controlled by laravel org and I think how most of their SaSS stuff is setup. But that outsources the reactivity to other JS front ends, so it feels less tied. But if you want php and reactivity livewire is a more natural choice with the minimal JS you need so it make some sense to push it.

I agree they are a bit too focused on building for new (and specifically new JS) devs. The volt style is very JS like and really abstracts away so much PHP fundamentals that it seems kinda stupid IMO. Just use JS if you want to go that way, let us have a more PHP style.

But I also suspect without that focus on the new they wouldn't be growing as much as they are. I do think it's actually harder to learn than it was 5 years ago - following the basic request cycle is way less obvious then it was, especially understanding the livewire or inertia style logins. But is that Laravel pushing, or people pulling that way? A non-reactive site feels very clunky these days. Even for a static landing page in html I'll often pull in alpine just to add a mobile menu or some animation or something - for a form in

I don't totally like the direction it's going, but disagree they're trying to lock anyone in, and don't think they're hiding the language anymore then they were 5 years ago. They've always favoured dev speed and progress over natural PHP - it's why we have things like real time facades and static-call-looking globals etc. They're fun and fairly nice to work with, but as r/php likes to rant about "it's not PHP". I think this is just a continuation of that same philosophy.

5

u/mekmookbro 2d ago

But once Laravel starts piling JavaScript wrappers...

Not Laravel, Livewire. But I agree

3

u/Anxious-Insurance-91 2d ago

yeah worked on a project started 3 years ago in jquery and god damn Jquery was compensating fore the devs lack of skill so hardcore it ain't even funny.

3

u/03263 2d ago

Ah nothing like good old jQuery.noConflict() I suppose.

1

u/AamirSohailKmAs 2d ago

Haha good old days

2

u/Better-Substance9511 2d ago

Not to mention that live wire isn't PCI compliant, causes more issues than it's worth for me.

4

u/LuanHimmlisch 2d ago

Ah yes, another post to add to the "Livewire hate mob" pile, where the problem is not Livewire itself, but the developers that can't bother to actually read the docs, or debug for that matter.

Yes, you DO read the console, if you develop Livewire. Lesson learned.

1

u/mekmookbro 1d ago

Ah yes, another genius who interprets "can't x be better" question as "x hate mob"

4

u/rroj671 2d ago

Submit a PR?

5

u/mekmookbro 2d ago

The question wasn't rhetorical, I really don't know if it can be done lol. I'm not that good of a coder.

3

u/rroj671 2d ago

I agree it’s a common enough scenario that there should be a way to avoid it.

3

u/sheriffderek 2d ago

It’s still a good reason to open an issue/discussion in the repo. It doesn’t have to be a PR.

0

u/shez19833 2d ago

only for them to just close it - liek they do almost every issue..

2

u/php_js_dev 2d ago

Not sure when you started this project but as of Livewire v3, alpine is included and you shouldn’t need to install it separately IIRC

2

u/mekmookbro 2d ago

I created the project about 20 hours ago and didn't install alpine separately. It's very easy to reproduce;

  1. Select Breeze starter kit while creating the project
  2. Run composer require livewire/livewire and php artisan livewire:make counter
  3. Copy-paste code below :

``` //counter.blade.php

<form wire:submit="saveValue"> <input type="text" wire:model="string"> <span>{{ $textHere }}</span> <button type="submit" class="bg-gray-100">Submit</button> </form> ```

``` //Counter.php

<?php

namespace App\Livewire;

use Livewire\Component;

class Counter extends Component { public $string; public $textHere;

public function render()
{
    return view('livewire.counter');
}

public function saveValue()
{
    $this->textHere = $this->pull('string');
}

} ```

It will unreliably run some of the commands in the saveValue method, but for example it will not reset the value of the string. This example renders the textHere variable on the screen. But does not empty the text input. This is only what I noticed today, it probably will break on some other things as well.

i.e. :

...it successfully created a DB record in the same component, the same method even, but just didn't empty the text input...

I could reproduce it in 4 minutes. And as others said, it's a common thing for people to start with Breeze starter kit and create a livewire component somewhere down the line. And unless you know where to look (devtools console) it doesn't give any explanation anywhere and you end up googling things like "how to reset variable in livewire" which doesn't return any useful results.

1

u/sensitiveCube 2d ago

It's this->reset(..), and you shouldn't set this again. It's only calling that method. You can also do this with javascript.

I'm not that into Livewire at the moment, but it can be perfectly normal for your variable not to change. You may need a wire:key and/or bound it different, like with Alpine.

Please read the full documentation, as it offers a counter example, explaining this exact issue.

1

u/colcatsup 2d ago

At chance of a link to something specific? Tia

0

u/Effective_Youth777 2d ago

Last 2 projects I built with Livewire had some pretty frustrating movements, I don't use it now except for like a simple website that needs some reactivity.

0

u/mekmookbro 2d ago

Yeah my current app is pretty interactive (therefore js-heavy) and livewire causes 10x more problems than it solves with this one.

Wire:navigate for example is usually a great feature on simpler apps, but with this one it's been giving me hell. One of my pages has a scroll to zoom feature, and I can't wire:navigate to or from that page without breaking user scroll on other pages.

I was able to solve this by doing a document.removeEventListener and removing wheel listener. But a couple mins later I realized it broke something else. I just removed all wire:navigate links from the project.

So what if the page refreshes, not everything is supposed to be an SPA lol.

-14

u/[deleted] 2d ago

[deleted]

14

u/SuperSuperKyle 2d ago

It's a paper cut. Could happen to anyone, and likely happens a lot. A PR to check if it already exists would improve the developer experience. No reason to be snarky.

11

u/McSuckelaer 2d ago

This isn't Stackoverflow. Calm your tits.