Laravel Livewire Course - How requests work to synchronize properties and events

Now we are going to learn in detail how Livewire works how it is possible for both sides client and server to communicate in a direct way

For this example temporarily place in your category form

<label for="">Title</label>
<input type="text" wire:model.live='title'>

With which every time we write and not only when we use an event the state of the title property will be updated

For this we are going to use the web developer console of the browser and place it in the Network section

Now we are going to work on the Savephp component and we are going to write slowly in any of the wiremodel text fields and we will see

 

Peticiones enviadas al servidor

 

If you did the exercise correctly writing slowly you will see that a request is made for each letter these requests are the way in which Livewire keeps the properties defined in the component class updated with the fields referenced as wiremodel based on these requests that it makes from the client to the server to keep these references synchronized

This control of requests that varies the operation depending on the type of directive that is being used is due to the livewireScripts decorator that must be placed when we want to use Livewire in essence the type of control that we discussed above

This decorator together with the livewireStyles decorator is defined by default in the Layout of layout/app.blade.php:

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
    <head>
        ***
        @livewireStyles 
        ***
        @livewireScripts
    </body>
</html>

To test this remove the script decorator and try using any Livewire directive for example the submit one and you will see that it no longer works

The livewireScripts decorator allows you to initialize all scripts to allow working with Livewire from the client side and this includes sending wiremodel updates click events submits etc The livewireScripts renders something like

<script data-turbo-eval="false" data-turbolinks-eval="false" >
    if (window.livewire) {
    console.warn('Livewire: It looks like Livewire\'s @livewireScripts JavaScript assets have already been loaded. Make sure you aren\'t loading them twice.')
}

    window.livewire = new Livewire();
    window.livewire.devTools(true);
 // ***
</script>

It is important to note that with Livewire enabled you can use the wiremodel as if it were a reactive property in Vue we make this statement as a way to understand how Livewire works although it is important to clarify that Livewire is not reactive that is through the title property if we define it in the component view

<div>
    <form wire:submit.prevent="submit">
        <label for="">Título</label>
        <h3 class="text-xl">***{{$title}}***</h3>
        <input type="text" wire:model="title">
        <label for="">Texto</label>
        <input type="text" wire:model="text">
        <button type="submit">Enviar</button>
    </form>
</div>

Youll see when you write something in the wiremodel

 

Actualización de la propiedad desde blade

 

The content is reflected and in this way you can understand the basic operation of Livewire to keep the properties updated this automatic update feature that is every time we wrote in a field it was updated on the server based on a request was how Livewire worked until version 2 in version 3 this function was deactivated by default when too many unnecessary requests were made to the server since in most cases we are going to want to update the attributes when some event occurs such as a click or a form submission

Video Transcript

Here I want to take a little break and mention or practice in a separate class what is a little How do the requests work for the full duplex update that we have here which was the one I was telling you about before understand that if we update here in Blade or here in the client but it is Blade it is updated on the server understand in the component class and vice versa that is we update the component class it is also updated here it is something we already did a little but it seems important to me to do a specific class for this in case you have any questions and also to practice here a little since this was easier to explain in previous versions of lare for the simple reason that it was automatic but here it is not anymore so so that we can see the exercise since the idea is to be able to see the requests here as it is updated we are going to place here at least momentarily just here point live

<input type="text" wire:model.live='title'>

What this means is that now it will be updated live that is every time we write it will be updated on the server so here you will see a request to the server as you can see Why I do this is a bit what was commented because in this way it seems easier to explain to you how it works and well basically How full duplex works again for the update in this case of this field but the same applies to this field or any other field that you want to place that is to the properties that we have defined here at the class level and that we are using through a Vue vmodel in quotes that we have here this would not happen with this one so that you also understand a little bit the sense Notice that here it does not update and here it does So here you can see Or you can also print the title as we did before here we place the printing of the title I am going to reload here

<label for="">Title</label>
<input type="text" wire:model.live='title'>

Since it was a change in the client and the changes appear here Of course on the server it would be seen if we had any active process there In this case it is when we send the message here that we see the title there and this has not changed at all I put a Im going to put a debug that has not changed at all But now that we have it defined live it seems to me an easier way to understand it Since before to do this update it was done when we sent the event Now here is when we write this obviously it is not recommended to have this update like this before

By default in Livewire in its version 1 and 2 that was every time we wrote a request was sent to the server and when we did not want this behavior we had to place some attribute there right now I do not remember what it was but for whatever reasons this was changed and now by default as I told you the update is suspended on the server until we indicate that we want it in case it is necessary since again the example that I mentioned before If you have for example 1000 clients connected and each one of them writes on average I dont know 100 times and you have this here active Then it would be 1000 because there would be too many requests to the server and you could obviously collapse it So to avoid that is why they deactivated it in version 3 starting with version 3 but a little this as I was telling you So this is what I explain to you a little bit here that you open the Network tab place Live here to do the exercise and start looking at the requests here Since in each one of these requests what it is doing is updating the status of the application understand the state as what we have in the component class and also what we have in Blade to do there what you do several times the full duplex communication and this exercise is more or less what we have done up to this point then well here you can explore the sent object Although it can sometimes be a little difficult to see since here you can see the Data here Note that it passes the title it also passes the text and later we will also see other options to update for example a certain time or only some properties etc But at least for now the basic operation is to pass as if the entire object as you can see to maintain exactly that update and of course it passes security things so that it knows that it is valid and is not something else or that it arrived complete So that is what you can see here the snapshot as is is the name that I was looking for and that is the basic operation this same if we look when we give here an s that when we are sending a request to the server is the same that we should see

Okay Im going to remove that blessed debug to make it easier to understand here I write a little bit the same thing again Well notice that it was written quite quickly and there as a giveaway then here you can see the same thing that we saw before the snapshot And if we give an s Notice that it is exactly the same which was the point that I wanted to get to of course some things change For example here there is a method here it would not be a method but it would be internal to livewire but in essence the snapshot is what we have here it is Exactly the same thing happens to it the text it passes it the title and everything else since that is the basic operation of the livewire that sends these types of requests and You could ask yourself how the hell does it do that well lets remember that around here somewhere in life we have a template a master template that we really havent explored much to see where we had it we have it here in resources views it was components layouts well my case was this one it may be in your case it is the one we have out here it may be this one Remember that at the beginning at least I had a problem with the error that it could not find the template

Disable Livewire JS

So I had to generate it and just this tag that we have here the script this you can also see in the manual installation steps of the Livewire in which you have to place these tags so that you can use these features of the livewire with the snot and it is something that this is translated if we give the source code here to see see source code Here it is Where is the Script to see aha Here it is I think it would be this one that does all this automatically through this Script that we have here and above is the css But well css And you have no doubt But if we remove it This is the Style to see where it is Here it is if we remove it to see it was this one that we are using is the other one I am going to remove all this to see because sometimes I have doubts I also in this Oh no to see if it is this one I am going to remove these here too Well here I paused I cleaned it up a little more for some reason it continues to inject it here is this one this is the one that is here doing the update for us as you can see then we would have to see Where is it taking it from that it is the Blade and I am not injecting it well it is a little strange in my case because I really shouldnt put that tag there here you can see that it put a message at the end and well magically it places it I dont know if there is some kind of strange catch there but it is that Script tag that is working in the same way around here we could force it a little more since it appears Then I remove it here manually we come here to Network I dont know if it stays loaded lets see if it works you can see that it doesnt work the update doesnt work here and that is exactly what this Script tag that we have here does enable everything that would be the livewire jdc surely there is some mw around there but well there is no need to remove it but it was to more or less give you context of how all this works so well that was basically the tests that I wanted to perform so that you understood the operation of livewire which is in a few words That is the trick as who says under the blanket that is to send server requests to be updating the status it is that simple so without further ado lets go to the next class

- Andrés Cruz

En español

Andrés Cruz

Develop with Laravel, Django, Flask, CodeIgniter, HTML5, CSS3, MySQL, JavaScript, Vue, Android, iOS, Flutter

Andrés Cruz In Udemy

I agree to receive announcements of interest about this Blog.