Yes it does. That’s why I included it, it’s more like a double check. Depending on the project, the auth policy can differ. In some weird cases, a user could return true to a policy (is in the same team, etc.) and you still do not want them to tamper with the ID. In that case the lock would be helpful.
Also, the ID is just an example. For example, you could also lock a variable that contains an action type like ‘create’ or ‘update’. A public variable can be useful for something like this, and you don’t want users to tamper with that.
Makes sense, thanks for the swift reply!
Also, just a heads-up: Livewire 3 will probably use an attribute like #[Locked] for it
Ruben van Erk you’re welcome! Yes, I noticed Caleb was still in doubt how the attribute is going to be. But a find and replace in the code base isn’t that much of a hassle 😉.