Now as a little bonus
at the end of this course section,
I wanna combine client-side data fetching
with server-side pre-rendering.
Not because we need it here,
but because it can be a pattern
which you do need in other kinds of applications,
where you wanna pre-render a basic snapshot
and then still fetch the latest data from the client
and therefore that is a pattern you should also know.
And I'll stick to the last sales page.
Here we are already fetching data on the client.
Now I just wanna prepare some data on the server
or during the build process as well.
And therefore we can add one of the two main functions
we learned about getStaticProps or getServerSideProps.
And I'll go for getStaticProps to pre generate that
during the build process and possibly revalidate it
after deployment with the revalidate key.
So for this we export the async function
getStaticProps here, where we get a context
which we don't need here though so I will omit it.
And then in there,
I wanna also fetch the same data which I'm fetching here
on the client side.
Now for this, we now can't use the useSWR hook
because this is not a React component down there.
GetStaticProps is not a React component function
and therefore we can't use hooks in there.
We'll have to write ordinary fetch code instead.
So I will grab this code here from the common that
I'd use a fact function where we did fetch manually
and I'll copy that into getStaticProps
and commented back in.
Now get rid of the code where we set some state
we don't need that here, and we're almost good.
Now we're using fetch here
and as I briefly mentioned before
you can use fetch here in getStaticProps
and getServerSideProps as well.
Next.js ensures that this also is available in this context.
So on the service side,
and then we just use it as we did above.
We pass the response, transform the data,
and now then once we're done transforming the data
here after this for loop, what now?
Well now you should keep in mind
that the function you have here getsStaticProps
is an async function.
So it wants a promise in the end.
And we do have a promise here.
So all I wanna do here in this second
then block is return my object
which eventually should be returned by getStaticProps.
I will return an object with a props key
where in there I have an object
with a key of sales, which holds my transform sales.
And here we could then also add the revalidate key
and set this to 10 seconds for example if we want to,
so that as you learned
this is executed again every 10 seconds
or at most once every 10 seconds after deployment.
And now we just also need to return
the overall promise chain by adding a return statement
here in front of fetch,
so that the overall promise with all its step
and the final data here is returned by getStaticProps.
Alternatively, we could of course also
use the await keyword here.
Then in the end we just would have written
response=await;fetch.
Then here we would write
const data = await response.json,
and remove this semi colon here,
remove this, then block here like this.
And now we would be back to the code
you recognize from before.
So that is how we could write this with a single wait.
Both works there is no better or worse alternative.
It's just different syntax for the exactly same operation.
So now we return our data as part of the props
and therefore now here in the last sales page
we of course should accept props again
and do something with those sales we receive.
The question now just is what should we do with them?
And I would say here, it makes by far the most sense
to use the props we get here
the pre fetched and pre-rendered sales as our initial state.
So the initial state for the sales state is prop.sales,
those pre-rendered sales from the server
or from the build process.
These are the sales which are used
for the initial state here.
They then can and will be overwritten
by the result of the client side data fetching.
But initially we use the sales,
which we get from getStaticProps
as our state for the sales state here.
And that means that now initially
this year will not return loading
because sales will not be undefined.
However, we should change this
from an or to an end operator.
If we don't have data and we don't have sales
then I wanna show loading.
But now we do have sales because we pre-populate them.
We initialize our state with the pre fetched data
from getStaticProps.
So now we'll make it past this if check
and render our initial sales here.
So that's not what will be pre-rendered.
And still when this component then runs in the client
it will fetch again to fetch the latest sales.
So if I save this here and I reload this page,
now we see what we saw before.
But if we view the page source,
we see now that our sales data here
is part of the pre-rendered page
and that's a difference compared to before.
Now if we reload again and the data would have changed
between the point of time it was pre rendered
and prepared and we visited this page.
If the data would have changed here
then we would see the updated data here,
since it is fetched in the client,
but not here in the page source.
Now that's hard to simulate here in development
since this will always trigger
getStaticProps for every visit,
but it's easier to show if I build this for production
and I remove revalidate so that this is not revalidated
after running it in production
because that again will make it hard to kind of
catch this page in an outdated state.
So if I disable revalidate here
and I now run npm run build.
So now we build a snapshot of this page
once during the build process and never there after
then we'll see what I just said in action.
So now last sales was statically pre-generated
as we can tell.
And now if I run npm start to start that production server
with the production ready bundle.
If I reload here again in the page source we see our data.
But if I now go to Firebase
and I add a third sale here s3
with a username of Julie and
and give this a volume of 70 let's say,
if we do that and we reload last sales again
actually we don't even need to reload
because this SWR hook saw that this page got focus
and it automatically re-fetched data
that's part of the magic this hook does,
but otherwise if we would have reloaded,
it also would have fetched that data again,
but in the page source of the pre-rendered page,
we don't see Julie anywhere
because it was not there when we pre-rendered the page
when getsStaticProps ran, but it is there
once we view this in the browser
because then this code runs on the client side
this component code and the client-side
data fetching kicks in.
So this hopefully also is clear
and combining pre rendering with client site
data fetching can sometimes lead
to the best possible user experience,
because you have some data right from the start
and you then update it from inside the browser.