Sign up to access "Livewire Performance" right now.

almost like a confirmation for deleting an employee. So let's go ahead and run phpArtisan LiveWire make and let's just say employee delete. Okay, so let's go over to our dashboard, add this to our dashboard, and then we can get started. So LiveWire employee delete, and of course we won't see anything, but our component is now there.

Now the first thing we want to think about is from the last episode, do we want to pass the entire employee object through to here? Well, to be honest, this would be absolutely fine. This is a component that's just shown individually on a page.

Of course, passing an entire employee object through to this would not matter, but I'm going to go ahead and pass the employee ID for the purpose of this, just so we can create that computed property to grab the employee out of the database. So at the moment, of course, we don't see anything,

but over in employee delete, which we're going to open up now, we can go ahead and accept this in. And first of all, we're going to go ahead and perform a query to actually show the details of the employee on this template. So let's go and create out that public employee ID property.

And inside of the array that we pass through to our view, we're going to pass through the employee by looking them up in the database. So employee and find, and this employee ID. Great. So let's pull the namespace in for employee.

And now over in the employee delete template, we can pretty much access anything inside of here. Are you sure you want to delete and let's say employee name, like so. Great. So that's pretty much our component. Of course, we've performed a query here because we are grabbing that employee by their ID.

That is obvious. But now what happens if I want to go ahead and create out a button here to delete this employee? Well, let's go ahead and just say yes. And let's just check out the design of this.

It's just on the end there. So I'm going to go ahead and wrap this in a paragraph tag. So it's a little bit more obvious. And when we click on this, we want to go ahead and confirm the deletion.

So let's say wire click, delete employee or confirm whatever you want to say. OK. So over in the component here, let's create this method out to delete this employee. Delete employee. And of course, here, what we're going to need to do is look them up in the database again.

So we're pretty much going to go ahead and copy and paste that code over. And then we're going to see how a computed property can clear this up for us. So let's just die dump on that employee just to make sure that's working. And let's go over.

Hit yes. And there we go. We get that employee dumped. Now, if we get rid of the die dump and just hover over the debug bar,

if we hit yes, you can see that we've performed another query. So this is not a massive deal, but we can improve on this. So we've got two duplicated queries because we have clicked yes. If this was any other action which required you to use that model over and over and over again,

of course, you would create more and more queries. And you can see here that if we just go up to each of these requests, each of these requests as we press that button is performing two queries. Now, the reason that each request is performing two queries is because

render or the component is being re-rendered. So we're looking the user up again. And then we're performing this query here to find the employee again. So every single re-render of this component after we click the button

as the side effect of clicking this button is performing two queries. Again, not a massive issue, but we can improve on this. And it's always good to improve on things even if they're very, very small. And of course, one database query can add up to thousands

depending on how many people are using your app. So what's the best solution? Well, it's to use a computed property. We've got the employee ID in here,

so we can create our computed property and access the employee that way. And then we'll take a look at why this is a faster solution. So let's change this or let's create a completely separate method in here called getEmployeeProperty.

So with computed properties in LiveWire, we prefix these with get and we add a property suffix on the end. And this ends up the name of the computed property. So now we're doing this in two places.

So let's go ahead and grab this out from here and pop that into there and return this from here. We can actually type today. And then down here, we can do exactly the same thing.

Get rid of this. So how do we access this? Well, just like a property. So this employee and then here, this employee.

And of course, you wouldn't assign it here. You would probably do this employee and delete. But we'll just assign it just so we can get the benefit of the re-render to see what's happened.

So technically, we're thinking we're doing the same thing here. We're just calling this from the same place. So surely, we're still going to have this called here when we re-render. And this is going to be called when we press that button.

And it's going to perform two database lookups. Well, the reason that this isn't the case is computed properties in LiveWire are cached. So once we have grabbed this employee property once,

that's going to be cached. And the same result will be returned when we access this again. So the first access of this is when we render. Then the second access is when we delete the employee.

And then any subsequent re-renders will just use this cached property. So let's go over and see the difference here. So we've got one query, which we expect. We're always going to perform that query to look the user up by their ID

or the employee, in this case, by their ID. But when we click Yes now, you can see that we're not performing an additional query. We're only performing this once.

So we're doing this for every single request because the re-render requires this to be pulled out. But we're only performing one query and not that duplicate. So we can pretty much use this again and again and again.

Now, the interesting thing is we can also do this in templates. So if we just come over to our employee delete template, rather than say employee name, we can say this employee name.

That is the computed property. Let's go over and give this a refresh. And that's the computed property on that employee. And we can just do this for any single property that we have,

for example, the ID as well. So again, we're accessing that computed property twice here. But because it's cached, we can use it in our template as much as we want

without it performing an additional query. So again, we're only performing one query now for every re-render of this component rather than two, effectively cutting our query count in half.

And we don't have a duplication, which is the most important thing. So when you're doing things like this, particularly combining this with things like

passing in an ID into a component where we want to look the model up inside of the component and not pass the entire model in, computed properties like this really, really help.

As long as you just make sure you monitor your query count, that you're not using too many queries, then you're good. So creating computed properties which are cached can be beneficial to reduce our query count.