Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

luisferfranco's avatar

I think I'm not understanding the livewire cycle. Can you help?

I'm using Livewire, and more specifically Volt and Alpine. I've always use the mount() method to initialize my variables, but recently something odd happened. This is replicable, and I think it has to do with my understanding (or lack of) of the lifecycle in Livewire.

A portion of my volt code is as follows:

So in mount() I'm initializing $tiposJuego, I'm gonna use it later for a select. But now I'll only display the data.

This works as intended the time it renders.

Now there's my Alpine. If I don't entangle the Laravel variable, it works, but if I entangle it, and use the toggle() method to change its value, the data in $tiposJuego is lost. It's like if it was initializing the whole component without calling the mount() method.

Checking the documentation it says the mount() method is called when the component is created. I'm okay with that, and I can solve my problem if I use the boot() method instead.

So I have some questions:

  1. Why does it clears the variable that comes from the relation ($tiposJuego) while the $otro which is a fixed value -as you can see in the code- remains the same, after the toggle() function is called?

  2. What is the correct way? I have used mount() for several years, should I use boot() instead?

  3. Now, wierder... but I think it has to do with how Alpine works... If I DON'T entangle the variable, the value in the $tiposJuego remains the same.

0 likes
4 replies
jj15's avatar

I've admittedly never used $wire.entangle() before so it's possible I'm not seeing something here, but your code looks like it should work as intended. I do know that the v3 docs have deemphasized its use due to little quirks like this.

Depending on your specific use case, is it possible for you to handle the open/closed state using only Alpine? It will stop wasted trips to the server to simply toggle a variable.

Also, for your $tiposJuego property, it may not be the best idea to load and store all of those models as a public property for performance reasons. Consider using a computed property for this.

1 like
luisferfranco's avatar

@jj15 Yeah, I oversimplified what I do with the entangle. In my app there are some initializations, some searches, and so on, other than toggling the variable. Since it wasn't working I started cutting things to the barebone problem, and came to this.

I'll check the computed variables, I haven't used any in Livewire, but I'm familiar with the concept from Vue

Thanks!

bvfi-dev's avatar

This is just my thought proccess, Im not sure If its correct, but its how I understand it.

  1. $otros is a collection of integers, it can be easily de/serialized, while $tiposJuego is an Eloquent collection of models. So, Livewire will try to rehydrate $tiposJuego, but it can get messed up during the update cycle while Alpine is entangling, basically clearing it. Why? You answer me that, my friend.
  2. I dont think boot() is the correct way, mount() is the right way to set the initial states. Instead, I would use updatedOpen() which will be called when open is updated. However, as a rule of thumb, I recommend ALWAYS TOGGLING IN THE CLIENT SIDE when possible. So, I would actually use $toggle Action in the frontend
  3. This is because Livewire doesnt see $tipsJuego change on the client side when its not entangled, so the data is never re-serialized, so it stays the same from the first request. But when you entangle it, then the rehydration cycle is retriggered. And this fails to make $tipsJuego exactly as it was.

So, if you want to entangle an Eloquent property, store the IDs or convert to an array: $this->tiposJuego = TipoJuego::all()->pluck('id')->toArray(); and If you need the model later, just re-query. And if you want tiposJuego to always be current on updates, then:

public function updatedOpen()
{
    $this->tiposJuego = TipoJuego::all();
}

Or in the render(). Use boot() only if you want the data to be loaded every time the component rehydrates. Then you have to think about optimization, depending how big your database is, by using computed properties and unsetting it when you need it fresh.

1 like
luisferfranco's avatar

@bvfi-dev never thought about the updatedOpen() looks much better than the boot(), certainly!

Thanks!

Please or to participate in this conversation.