Data about properties in Laravel Livewire, locked properties
Blocked Properties
Below is a ShowPost component that stores the ID of a Post model as a public property called $id. To prevent a curious or malicious user from modifying this property, you can add the #[Locked] attribute to the property:
use Livewire\Attributes\Locked;
use Livewire\Component;
class ShowPost extends Component
{
#[Locked]
public $id;
public function mount($postId)
{
$this->id = $postId;
}
// ...
}By adding the #[Locked] attribute, you ensure that the $id property will never be altered.
Another way would be to declare the property as private:
private $id;Resetting properties
We can also reset properties using the $this->reset() method:
class ManageTodos extends Component
{
public $todo = '';
public function addTodo()
{
$this->reset('todo');
}
}Supported property types
Livewire supports the following primitive property types: array, string, int, float, boolean, and null:
class TodoList extends Component
{
public $todos = []; // Array
public $todo = ''; // String
public $maxTodos = 10; // Integer
public $showTodos = false; // Boolean
public $todoFilter; // Null
}Video Transcript
To close, I would like to mention other features that I consider interesting for the properties part. Here I took the following. I am going to leave this one for last because it seems to me the most interesting. In case you need it, you can reset a property, the same would be to place everything equal to empty here or directly do a redirection as we did for the filter, but this would be the official way. Now, I leave it for your consideration. And here we also have types of properties allowed. In this case, although they do not clarify it here, this is the official documentation. It would be for wire models, since for example, here we are also using a check type to define the post and the component takes it perfectly, but this would be what we can use: empty arrays, integers, a null, a boolean value, which would be exactly as indicated here. Properties that we can easily cast to JSON. So, as they say, the matter is a little clearer. And again, here you have the official documentation. If you want to see other things, I would recommend some more examples here. Let's see this one, which I find interesting as well.
This is the way we have to block properties since the problem we have here is that we can access from here from the view we can access those properties and maybe as the official documentation indicates, you can read it there a curious or malicious user can modify at the level of the wire model type fields that we have by placing some property that we have not defined in this example of the video would be the ID.
It can be seen that from the developer console I duplicate the title field and I put id and I modify the value of the new field, we will see that Livewire automatically takes the field established by the attacking user, which is a big security flaw. We are injecting values so for this what the Livewire people tell us is that we can block this type of properties therefore it would already be a security measure simply here we place locket:
And if now I try to do the previous test, we will see a Livewire error that says that the property is blocked.
So notice that we were actually passing it because if this flag no longer jumps it is because we made that kind of injection, even so it seems a little clear to me, it is difficult to understand that the user can make those kinds of changes. But well, that is what there is, so again, in case it is necessary for you and you have to manage some property there that is delicate and that you do not want to expose, this would be a good candidate, another way, although that is not recommended by the people at Livewire.
Defer update for wire:model
A critical thing to keep in mind when working with wire:model is that by default when detecting changes, Livewire sends messages to the server every few milliseconds to keep what's on the client in sync with the server and vice versa.
The problem with these requests is that, if the default configuration is used, too many requests are sent to the server and if we have multiple clients connected at the same time sending this type of request, it can cause performance problems and even server errors. Thus, each request causes the server to require more and more resources that may not be available due to high resource demand.
Luckily this problem, no longer occurs in modern versions of Livewire starting with version 3, therefore, the options we have here DO NOT apply or cannot be used for new versions of Laravel and are explained for purely informative purposes.
To avoid these problems, we have to define extra features on our wire:model which can be of three types; for these examples, you can use any of the form fields that currently exist for posts or categories; for example:
resources/views/livewire/dashboard/post/save.blade.php
***
<div class="col-span-6 sm:col-span-4">
<x-label for="">Título</x-label>
<x-input-error for="title" />
<x-input class="block w-full" type="text" wire:model="title" />
</div>
***.debounce: Modify the update time
This setting modifies the update time of the wire:model field; default is 150 milliseconds; for example, to modify this time to 500ms:
<x-input class="block w-full" type="text" wire:model.debounce.500ms="title" />This feature can be used if you are using the live option that allows updating the property associated with the wire:model every time we write, leaving it as:
<x-input type="text" wire:model.live.debounce.500ms='title' class="w-full" />.lazy: Send updates when losing focus
This setting disables synchronization of the wire:model field and only updates the state when the field loses focus.
<x-input class="block w-full" type="text" wire:model.defer="title" />.defer: Disable updates
This setting completely disables synchronization of the wire:model field; therefore, the changes made in said field will be sent when messages are sent to the server provided by any other update process in the application.
<x-input class="block w-full" type="text" wire:model.defer="title" />Video Transcript
Here I want to quickly tell you about some ways we have before working with the properties and this is not something that is simply used there we have a small variant that I will explain to you but this way it seems very important to mention it because even if it is when you are consulting old documentation you may see these lazy debounce options and you do not know exactly what they are since none of them are applied in modern versions of Livewire since from version 3 this changed a little and it was what I told you at the beginning of the course the main change that exists between version 2 and 3 which is the last date is that version two every time we update a field it is automatically updated also on the server, that is, a request is sent to the server to update that state, which made absolutely no sense and I really never knew why it worked like that since there was the Beta version one and two in which Livewire worked in the way mentioned above. they are making a small parenthesis aside those are the things that sometimes the Laravel community or the Laravel people do and I really don't know why they make those kinds of disastrous developments because it doesn't make sense that it came out like that then well as I tell you all this always has to be handled with care luckily the Laravel people reconsidered and it no longer works like that it works as it should work that we here can customize this to taste as we want and when a strong event occurs that we determine we update on the server in this case through a submit but imagine that we had this form and every time we write suppose I don't know that in the end we have 500 interactions with this form 500 requests are made to the server that doesn't make sense because we are not taking advantage of it we don't need it therefore it shouldn't happen instead of simply an iteration or an interaction better said with the server that just when we send the same here through the event That does make sense the update never had much sense of a practical nature because this only the part of the how What synchronization says is that we take advantage of it when we want to manage the resource, which is when, as they say, we dump the data that we have here, we dump it here so that it is synchronized and here we take advantage of what is Livewire and with this everything that is above that would be the validations and of course here how easy it is that we can reference each one of these Fields through these properties that we have defined here And in this case, either create or update something, but for the rest it didn't make sense for me to do that update. I'll explain this to you a little because as I was telling you, it seems important to me that you understand that this existed before and that it no longer exists and therefore you understand why it no longer exists because again it no longer works in the way mentioned with practically automatic updates. Even so, I'm going to mention this a little bit so that you can see how it works. I'm going to leave B's for last.
Lazy and defer
I'm going to start here with Lazy, what did Lazy do, which again, notice that it no longer exists if we look here for the modern documentation, which would be this. Notice that if we search for this is another thing that has nothing to do with what we are talking about is to do the Lazy on a component while the old documentation appears previously its explanation here why it is like the defer and the debounce the defer what it does is defer the update for when another field is updated basically this is also updated notice that now it is working as who says the other way around because now before as I tell you every time we wrote this was what happened I am going to come to some field I am going to place here the Live point that Remember that we use it in the share filter I come here This is what happened before every time we wrote an update was sent something that does not make sense because of what was commented before and these were characteristics that we had to precisely avoid this behavior something that again I did not understand I will never understand what the Laravel people were thinking about doing this type of development in this way but this no longer exists luckily then the defer what it did was that I cannot test it because of what was mentioned that we for example could write here everything we want if we put diff here we wrote everything we wanted and as a result of the update of another field it was used and this one was also updated that was what it did while the Lazy simply deactivated the synchronization of the field and the state of the field was updated when the focus was lost that made a little more sense But again usually the debounce was not necessary Yes, it is a bit more interesting to use it now, since what it does is create a delay of a certain amount of time, in this case specified 1 second. I think you can also set it in seconds, but that depends on you. We can try it now, indicate here that you want the update to be performed not automatically.
Suppose it was this every time we are writing, otherwise after 500 milliseconds in this example, something that would make more sense. The user is left, as they say, with a time to finish completing the sentence and then make the request and there are not so many updates and in the end everything goes to hell. So I say this that it makes a little more sense precisely because of Live since here notice something interesting and that is that if you write quite fast. Notice that it only gives a chance for an update to be made here I wrote like six characters and it was only updated once, therefore something of that is already implicitly implemented. I don't know how much the default time is, but we can also modify it and it is here where we go to the modern documentation and Notice that it is not the same syntax as you can see because again now everything works in a different way. Before it was directly on the model and now it is only when you are going to use it since when you are using Live is that you return in quotes to the old approach and therefore here you can place the delay time, well apparently it is only milliseconds according to what I am reading here. So here we can try a little bit you can put here the Live point b and indicate the delay time Then you put another point I'm going to put 500 milliseconds for example we do this we come back here And then now I have half a second to write and then it updates Although it will seem like it's taking a little more time But you can see that there is a delay there:
<x-input type="text" wire:model.live.debounce.500ms='title' class="w-full" />And it's that simple this again if it makes sense if you want to use Live you can at least customize the delay time so that it gives a chance to write and it updates otherwise none of the rest has a purpose and that was a bit what I wanted to mention to you So we basically conclude this class the next thing I wanted to tell you is that this topic is a little bit more abstract so basically it's going to be like this theoretical I'm going to explain a little bit how it works what is the purpose of it but really many of them don't have a place to do an example an exercise since it's I would need a slightly more complex project with more, as they say, to remember that this project is quite simple, so little by little I will explain it to you, mostly in a theoretical manner, so without further ado, let's move on to the next class.
- Andrés Cruz
Develop with Laravel, Django, Flask, CodeIgniter, HTML5, CSS3, MySQL, JavaScript, Vue, Android, iOS, Flutter