We added a simple pagination
bar to our Reviews page,
that allows users to go to the
next and previous pages.
However, at the moment we always
display the same 6 reviews,
no matter what the "page" number is.
Let's see how to fetch different
data from the CMS.
In the "getReviews" function
we already pass a "pageSize" parameter
when calling Strapi,
to limit how many results we get back.
But we can also pass another parameter,
if we look at the REST API documentation.
When using "pagination by page"
we can pass a "page" parameter,
that is in fact the page number,
and defaults to 1.
There's also a different approach,
called "pagination by offset",
where you pass "start" and "limit"
parameters instead.
This is more similar to how databases work.
But we'll use "pagination by page"
that's slightly easier.
The only difference is that
in this case you pass which page number you want,
while with the "offset" approach you pass
the index of the first entry to be returned,
which you can easily calculate
based on how many entries per page you want.
Anyway, we'll use the "page" number,
so let's add it as an argument to this function,
and then we can pass it in
the "pagination" options
when sending the request to Strapi.
Now, since we're changing the arguments
we better check where this function is being used,
to make sure we don't break some existing code.
We're calling it in the ReviewsPage,
that's what we're currently working on.
But also in the HomePage,
and we don't need pagination there,
we simply display the latest 3 reviews,
and that's it.
So, what happens if we leave
the HomePage as it is?
It will not pass a second
argument to "getReviews",
and that should be fine I think,
because if the "page" argument is undefined,
then it will not be sent in the request,
and therefore Strapi should default to page 1.
We can treat the "page" argument
to this function as optional.
But let me check if it does
actually work that way,
by uncommenting this log statement
that will print the full request "url".
Let me show the logs,
and go to Home.
The page still displays correctly,
and if we look at the logs
we can see that it's passing
the "pageSize" in the "url",
but there is no "page" parameter.
So it does work as I expected.
We can now go and update the ReviewsPage.
Here we do want to pass the "page" number
as the second argument to "getReviews".
And if we go back to the Reviews
page in the browser,
it's still working fine.
This time in the logs we can see that
the "url" does include the "page" parameter.
This means that, if we go to the next page,
in theory it should load different
data from the CMS.
But looks like the browser
is showing cached content.
Sometimes you just need to click reload.
There you go: we now see different reviews.
And the request "url" has
"page: 2" as a parameter.
So it should now fetch the right data
for each different page number.
And that's the main pagination
functionality working.
Now, rather than hard-coding the number 6 here,
let me define a separate constant,
we can call it "PAGE_SIZE".
This way it will be clearer
what the first "getReviews" argument actually is.
That was just a bit of refactoring,
it should make no different
in terms of functionality.
We can see 6 different reviews on each page.
Of course, the last page may have less than 6.
Now, our pagination feature
is not quite complete yet.
There's nothing stopping us from clicking next,
even though there are no more pages available.
Ideally we should disable the next link
once we reach the last page.
We'll take care of that in the
following couple of videos.
But we did implement the main functionality,
that is displaying different reviews
for each page number.
We're doing that by passing the
"page" parameter to Strapi.
By the way, let me comment out the line
where we log the "url" every time.
But in "getReviews"
we accept the "page" number and send it to Strapi.
And then in the ReviewsPage
we pass the "page" number extracted
from the "searchParams"
as the second argument to "getReviews".