Anyone please feel free to correct or add on to this. For future readers, this is based on 0.7.0, and things could change.
Well, it is, kind of, but not in the way you want to use it; not in a way that you can bind the properties to inputs (more on that later). You can however
->toArray() it to a different public property and bind the properties with dot notation so you don’t end up with such a monster of a component defining a public property for each thing you want to bind. Syncing them back together, validation, and authorization is still on you.
Cool, problem solved right? Well not exactly. When you combine that:
- State is being stored in 2 spots,
- How the cache was being maintained to keep it manageable,
- Actions a user could do.
A certain mixture of the three would cause public and private properties to become out of sync, and things would break.
- The model name/namespace
- Database connection name
- Loaded relation names
This is what the queue worker uses to pull the model out of the database and do whatever needs done. The whole model is not being serialized and passed, only those four things. Or else we would be back to the problem of exposing to much to the front end. This is also why you can’t data bind in the way you were looking to do.
You can see this by going into your console and starting with
livewire.components.componentsById. You will get a list of ids livewire uses, and the names you assigned of the components on the page. Tack on the id and then data:
So your queue, and now liviewire, has the information it needs to reach into the database and pull what it needs to work with. State is only in one spot and stays in sync, your model isn’t broadcasted to the world, and life is good.
Now why not just keep the model information there on the back end and hit the database every time instead of passing that information back and forth each time? Well it couldn’t be dynamic, and another behind the scenes aspect that was implemented with this is the database is only hit when it needs to. Without that life wouldn’t be good. If you have a text input and you’ve seen how many requests are sent back and forth as the user is typing, you don’t want your database being queried every time for no reason.
So in the end, it didn’t really change the way you code that much (although in a roundabout way it did give us computed properties). But with the other proposed solutions at the time to fix the problem, the way you code would have changed.
Hope that helps clear it up, and you can go more in depth here, here, and somewhere in here.