Client-Side Caching

[00:00:00]
>> Now, if you go back to the homepage, you'll see that we've created a problem for ourselves. We've got that footer at the bottom of the screen because we added some CSS that's controlling the height of the main element that contains all of this content. And we can no longer scroll down the page because our main element has a maximum height.

[00:00:19]
And we don't really want that, but we can't not have a height on the main element when we've got an infinite loading page, because otherwise we'll never be able to get that windowing effect. So we need to have some way of controlling the layout based on what type of page we're on.

[00:00:35]
And this is where SvelteKit's data loading as a separate step from page rendering becomes really useful. We're gonna be able to distinguish between two types of pages, pages that have an infinite loading component and those that don't. So I'm gonna open the page.ts that we were looking at before, and I'm gonna add a new value, infinite true.

[00:01:01]
And in our layout component, We have access to the entire page data if we import the page store. So let's do that, import {page} from '$app/stores'. If we add a class name to the main element of infinite, Which is gonna be true if any load function that was involved in rendering the current page returned an infinite property.

[00:01:37]
And now the styles that we applied to the main here, we're only gonna apply these if it is an infinite page. Right, so our homepage is now fixed apart from a glitch on the nav that I apparently just introduced. But the infinite loading page works as we would hope.

[00:02:05]
We got a question from the crowd?
>> Scrolling up and down causes re fetching or is it cached somehow?
>> So someone just asked a really great question, is the data cached already fetching it a new each time? So we're keeping this stuff in memory as we're scrolling.

[00:02:29]
And so, if we scroll all the way down, we are fetching more data, we're fetching more data, we're fetching more data. But as we scroll back up, we're just rendering the data that we already have in memory. We're only gonna start loading more data once we get to the end of the scroll window.

[00:02:45]
And because we've already got all of this data, we're not gonna get to the end of the scroll window until it is in fact time to load more data. But there is a really useful thing that we can do since we're controlling the data loading in a universal load function.

[00:02:59]
And that is we can add some client side caching of our own. And that's useful because if you look at this front page here, we're already making a request to the trending API in the now playing API, and the upcoming API endpoint. And it would be nice if we could just reuse that data when we navigate to these pages.

[00:03:18]
So let's go into our API helper. And we'll actually go ahead and implement that. So open lib/api.ts, and inside this get function, we can create a cache. This is gonna be a new map, right? Super naive in a real app you would have a little bit more of a sophisticated caching policy than just add everything to a cache map.

[00:03:50]
But It's perfectly fine for this demo, so we're gonna create a string which is a url, and it's gonna be all of that data there. And I'm gonna replace that with a reference to a url. And now, if we've cached this data already, then we're just gonna return it directly from the cache.

[00:04:14]
If cache.has(url), return cache.get(url), otherwise we'll make an API call by calling await fetch get the data const data = await response.json(). And then we're gonna add that to the cache. And for good measure, let's add some logging when we get a cache hit versus a cache miss.

[00:05:00]
We'll bring up the console. And so when we load this page, we've got a bunch of cache misses. But that's okay because we're using SvelteKit's built-in fetch and what's actually happening here is the data is being fetched on the server and then the response is being inlined into the HTML.

[00:05:22]
So that when we fetch it in the client during hydration it's just grabbing the same data that was already fetched on the server. So we don't have a duplicate network request and that allows us to guarantee consistency. Now, if we just clear that and navigate to the trending page, then hopefully, we got a cache miss, so disappointing.

[00:05:43]
That's because we have a default page there. So let's get rid of the page equals one in the case where no page is necessary. Or alternatively, what we could do is in our root page load function, we'll just always default to page equals one. So go to the root page.ts over here.

[00:06:11]
And in each of these, we're just gonna add page 1, like so. Right, let's go to the homepage and navigate to the trending page. All right, we've got a cache hit for the first page and a cache miss for the second page, and then we will continue to get cache misses for the subsequent pages.

[00:06:43]
But if we now navigate back to the home page, we are not gonna be fetching any new data we're getting all these lovely cache hits. So we're gonna get instantaneous navigation. And this is something that you can only really do in a framework that has universal load functions, as opposed to making you go back to the server for everything.

[00:07:02]
So obviously, there is a time and a place for loading data from the server. But loading data directly from the client is really good particularly for stuff that involves things like real time and so on. And so SvelteKit gives you both of those options for whatever you need when you're building your app.

[00:07:22]
That was a great question that segs so nicely into what I was about to cover.