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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
If cach.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.
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 sculpt gets 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.
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.
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 route page load function,
we'll just always default to page equals one.
So go to the route page.ts over here.
And in each of these, we're just gonna add page 1, like so.
Ryan, let's go to the homepage and navigate to the trending page.
All right, we've got a cash hit for the first page and
a cash miss for the second page, and
then we will continue to get cash misses for the subsequent pages.
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.
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.
That was a great question that segs so nicely into what I was about to cover.