در حال بارگذاری ...

Introducing Computed Properties0:00

Livewire has computed properties, and you can think of them as accessors on model classes. They are, well, they are essentially methods that we can use to access data, and that data is cached, and we can easily create a computed property by just defining a method inside of our component class. The name of that method needs to be the name of the computed property that we want to use, and then we just decorate it with the computed attribute. Now I've called this articles because I'm going to change how we provide articles to the Vue. I want to cache all of this. So we're going to take the code from the render method, and we're going to paste that into

Refactoring Query into Computed0:43

I want to cache all of this. So we're going to take the code from the render method, and we're going to paste that into articles. So we are still going to build our query, we are going to determine if we want to show the published or all of them, but when it comes to returning, we want to return our paginated results, and then it is that that is going to be cached. But by doing this, we need to change our render method because now we don't need to perform our query here, and while there's nothing that says that we can't provide the articles like that, we don't really need to do that anymore. In fact, we can just make this a simple call to Vue because we can directly access our

like that, we don't really need to do that anymore. In fact, we can just make this a simple call to Vue because we can directly access our computed properties inside of the Vue itself, but we can't use the articles property like we did before. We have to use this articles, and I think we did this in three different places. So we did it for the links at the top, then whenever we iterate over the articles, and then finally at the bottom for the other links, and that's it. In the browser, we see our list of articles. We can navigate between the individual pages, and everything looks and behaves like it did before.

We can navigate between the individual pages, and everything looks and behaves like it did before. We can even select one of these to delete, and whenever we confirm the deletion, we'll see that the results updates that went from 26 to 25 results, and of course, the articles that we see inside of the page is different than what we had before. Now you might be thinking, well, what's the purpose then? The behavior, the functionality is all of the same, and besides, I thought we were going to use the computed properties so that we can cache that information. Well, yes, but by default, computed properties last for a single request, and it's not just hitting the refresh button on the browser.

Well, yes, but by default, computed properties last for a single request, and it's not just hitting the refresh button on the browser. It's any request, including Livewire requests. So whenever I click on a delete button, and then confirm that delete, that is issuing a request. The articles is then going to be pulled from the database, and those articles will then be used to render in the browser. So really, once the articles are rendered in the browser, that's it. The cache is gone. However, we can make some changes so that we do see that the cache is actually being.

Demonstrating Cache Staleness2:51

The cache is gone. However, we can make some changes so that we do see that the cache is actually being used. So whenever we delete an Article, the first thing I want to do is access the articles here. Well, by doing it here inside of the delete action, we are fetching the articles, and it is going to be cached. So let's do something like this. If the count of the articles is less than 10, then we don't want to delete. So we'll just throw a new Exception, and the message doesn't matter.

If the count of the articles is less than 10, then we don't want to delete. So we'll just throw a new Exception, and the message doesn't matter. We'll just say nope. And if this condition is false, then we will actually delete the article. But bear in mind that by the time we delete the article, we still have a cached set of articles. And that cached set is going to be what is rendered inside of the page because, well, it's cached. So if we pick one of these to delete, and let's make sure that we are on a page that has at least nine items, and we'll just delete this one.

So if we pick one of these to delete, and let's make sure that we are on a page that has at least nine items, and we'll just delete this one. Pay attention to the status information showing 11 to 20 of 25 results because whenever I click on OK, it looks like that nothing happened. However, whenever I refresh the page, then we can see that, yes, there was an article deleted, and now we see the new list of results. Now once again, we see this behavior because whenever we attempt to delete an article, we are accessing the articles. So this is the first time we access our articles. It's going to fetch those articles from the database.

Invalidating with unset()4:25

So this is the first time we access our articles. It's going to fetch those articles from the database. It's going to cache the set of articles that we are going to display so that whenever we delete the article, that doesn't break the cache in any way. That just changes what we have in the database. So then whenever we display it in the view, we still are displaying that cached set of articles. So what we want to do then is essentially break that cache, and we can do so calling unset, passing in this->articles, and that is going to break the cache so that the next time we access the articles property, which would be for displaying the list of articles

unset, passing in this articles, and that is going to break the cache so that the next time we access the articles property, which would be for displaying the list of articles in the view, we will have a fresh set of articles. So let's pick one of these. We'll delete it, click OK, and notice that the results changed and the list of articles changed as well. Now before we move on, I want to show you that we can delete the render method. All we do inside of that method is return the view, and the name of the view follows Livewire's conventions. So Livewire is going to automatically display our view.

Livewire's conventions. So Livewire is going to automatically display our view. That's not what I expected to see at all, which makes me think that AdminComponent has a render method, and it does. So AdminComponent doesn't need a render method. We can get rid of that. And so now back in the browser, we can see our article list. So by using a computed property, we now have the ability to essentially streamline our component. If we want to get rid of the render method, we can.

Persisting Cache Tradeoffs5:58

component. If we want to get rid of the render method, we can. Now we wouldn't be able to do that for every component, but in this particular case, it makes perfect sense to do so. So by default, a computed property's cache lasts for a single Livewire request, but we could persist that cache throughout all requests by using the persist parameter. We'll just set it to true. So this will cause our article's property to be cached for every Livewire request for a single page load. And I feel it's important that I make this distinction because I use this term request.

a single page load. And I feel it's important that I make this distinction because I use this term request a lot, and it can be a little confusing. I'm talking about Livewire requests here. And we can see that by going back to the browser. So let's just go to a different page, but notice we can't go to a different page. The URL at the top is definitely changing. We are on page three. If I click on page two, the URL changes, but I can't click on one because as far as the UI is concerned, it thinks that we are on one.

If I click on page two, the URL changes, but I can't click on one because as far as the UI is concerned, it thinks that we are on one. And we're seeing this behavior because our list of articles is cached for all requests that are made by Livewire to update the UI. Now we can click on create article, and that will navigate us to our create form. And we can actually create a new article now with some content to go here. Let's say that we want this published, and we'll save it, but we can't navigate to the page to see that new article. We have to refresh the page, which loads a new fresh set of articles so that then we can see our articles in the page.

We have to refresh the page, which loads a new fresh set of articles so that then we can see our articles in the page. So to make this work like it did before, we would have to break the cache for basically everything that we click on. Showing published properties, well, that doesn't even work. So practically everything that we can click on, we would have to break the cache. And that's not very useful in our case, so let's not persist our articles. But let's do uncomment this code once again, just so that we can have that in place. So with a computed property, we can cache for a single request. We can persist the cache throughout multiple Livewire requests within a single page load.

Caching Across Components8:09

So with a computed property, we can cache for a single request. We can persist the cache throughout multiple Livewire requests within a single page load. But then there's a third option. We can actually cache a component across all instances of that component. For example, our ShowPublished component, every page load, we are fetching that fresh from the database, and I think that is something that we could cache. So inside of our PublishedCount component, we'll get rid of the count property because we are going to create a computed property called count, and we're just going to replace mount with count. We do need to return the result of getting the count of published articles, and I think

mount with count. We do need to return the result of getting the count of published articles, and I think inside of the view, all we need to do is say this count. But that's not really going to be good enough. We want to actually cache that, and we can do so using the cache parameter. We can set that to true. But if we are going to cache that, we need to set a key so that we can break that cache whenever we need to. So we set cache to true. We give it a key, and inside of the page, we will refresh when, well, it's already cached.

So we set cache to true. We give it a key, and inside of the page, we will refresh when, well, it's already cached for us. So we see that loading flashes, but then we see the count there. But of course, this count isn't going to change unless if we break the cache. So we can create a new article with some content, and we'll hit Published. We'll save it, but the PublishedCount doesn't change because whenever we create a new article, we need to break that cache. The same is true for deleting an article, and really for editing an article because we can come in here and we can make one published, in which case we want to update that count.

The same is true for deleting an Article, and really for editing an Article because we can come in here and we can make one published, in which case we want to update that count. And just to show that this is cached across all instances, let's open up a private tab. We'll go to the same page. We'll see that it's cached there. I could open up another browser, and we would see the same result because it's cached. It's using Laravel's cache, except it is very easy to use because all you had to do is say cache true and then give it a key. So we need to visit the places where we can update, create, and delete articles. So first of all, that's going to be inside of delete.

So we need to visit the places where we can update, create, and delete articles. So first of all, that's going to be inside of delete. And what we need to do is call cache forget and then the name of our key, which was what? publishedCount. So that is the key that we will forget. And we want to use this same line of code inside of our ArticleForm class. Computed properties cannot be used inside of a form object. We can only create and use them inside of a Component class. So just keep that in mind. It would be cool to have a computed property here inside of the form, but we can't.

So just keep that in mind. It would be cool to have a computed property here inside of the form, but we can't. And that's fine. So the two methods we need to focus on are store. So after we create, we will forget our cache. And then after we update, we will once again forget our cache. So let's visit this first article once again. Let's unpublish that. Let's save that. We can see that it loaded the new cache.

Let's save that. We can see that it loaded the new cache. And now whenever we refresh, we see that new published value. If we edit this once again, we'll see that it will load fresh from the database to show that we have seven published articles. So computed properties are very useful. They allow us to, of course, access data, but also cache that data. We can cache that data for a single Livewire request, or we can persist that cache throughout all Livewire requests within a single page load. But then if we actually need to cache that information and use it across multiple refreshes.

throughout all Livewire requests within a single page load. But then if we actually need to cache that information and use it across multiple refreshes of a page, even across multiple browsers, we can cache that computed property as well. The only thing to remember is that if you are caching something, at some point in time, you're going to need to break that cache. So always keep that in mind when using computed properties.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟