About the problem where our users won't ever get fresh data unless they do a hard refresh, we can do something similar to a caching technique called stale while revalidate. Let me bring up the first result here in Google. dev as stale while revalidate helps developers balance between immediacy loading cached content right away and freshness ensuring updates to the cached content and used in the future. I highly recommend that you read the entire thing.
It's really interesting and it's going to be helpful. But let me just summarize the whole thing for you. This technique will serve the cached response to the user while rerunning the request in the background to check for any updates. So the user gets an immediate response from the cache.
And in the background, the application is running the request again, fetching the data and comparing it with the cache. If there are any changes, it will clear the cache and update it with the new data so that future requests gets the new data. And we can do something similar in our application. Right here inside the store, I can add an if condition.
Let me do that here. value, it has any data. then I would like to do something. I want to synchronously call the project's query, then get the data out of it, So that will pass an object.
I can destruct the data out of it. And then I can compare the data, the new data with the data that I have in cache, which is inside this projects state. So I'll create an if condition. And since these are arrays with objects, I can use JSON stringify to make them just JSON stringified text.
So I'll stringify projects dot data. sorry, dot value, which is the cached data that I have and check if it exactly matches JSON stringify the data I got. And if that's the case, if they exactly match, I would like to console log cached and fresh data matched. Else I would like to console log something has changed.
Now, Let's see that in action back to our app. And let me also bring up super pays and then projects now back to the application and our bring up the console before we do any tests. So this is the initial fresh data. If we navigate away and then navigate back, the data is served immediately.
And our cash has been verified in the background. So cashed and fresh data matched. But if we do any changes, for example, let's change the name of the first project. I'll change it to changed.
Enter. And now I'll navigate away and then navigate back. Something has changed. So our logic perfectly works.
All what is left is to serve this new data. Right now, we just get the previous data because we just console logging things. But in fact, all what we need to do is to say that if they exactly match, then you don't have to do anything. Just return.
Keep using the cached data. But in case something actually has changed, we need to do something about it, which is use that load projects function that we created, which has the useMemoIs. And this composable from view use is offering something called delete. It's a method that can be attached to whatever the function that is inside useMemoIs.
So if you pass delete and then pass the key that you agreed that this will be the key for the cached data, and we did so right there, we pass the projects to the function and this way it has been used as the key for the cached data. This will delete the cached data. So for future calls, it will not have any cached data to serve. Therefore it will fire a new request and we'll get the fresh data.
So let's save and see that in action. I'll do a hard refresh. I got the data, the initial data. I'll go anywhere, then back.
Data is served immediately. Nothing has changed and the data matches. Now, if we change something else, maybe the second project changed again. And enter.
Now, navigate away. Navigate back. Something has changed and we got served the cached data immediately. We didn't get the updated or the fresh data.
But for future calls, if I navigate away again and got back, here it is. The data has been changed and we got the fresh data. The benefit we gain out of this all is basically just the immediate response. Of course, there are some problems in this implementation, like it works really nice on servers because they are dealing with maybe thousands of requests.
So only one request will get outdated version of your application and the rest of requests are going to get the new and fresh data. But for a small website, according to the nature of this website as well, maybe you need something fresh all the time. Maybe you don't need something like stale while validate or any other technique. Maybe you just want to serve the fresh data.
So it's totally up to you, but it's worth learning. And actually we can extract all this into its own function. So I'll create a new constant validate cache. And that will be a function.
And it just does everything here. So I'll cut this, paste it right there, and use validate cache right here. And it doesn't really matter if you put it in the beginning or the end. After all, this is not going to pose any requests.
This is always going to be triggered after that. Because this is using await, and this is using that. And that's it. You are now familiar with caching techniques that you can use with Pinia.