Our "getReviews" function now calls Strapi,
fetching the 6 reviews that
we can see on this page,
each one with its own title and image.
If we try opening an individual review however,
we'll now get an error,
because it's still trying to
load a local Markdown file,
instead of calling the CMS.
Let's go and open the ReviewPage.
In this component we call "getReview"
to load the data,
and in that function we call "readFile".
But, in the "content/reviews" folder,
there is no file called "hades-2018.md",
because that review is only available in the CMS.
So, we'll need to rewrite the "getReview" function
to fetch the data from Strapi as well.
Let's start by testing the API call separately,
using this "strapi-request" script.
Let me put the response file on the side,
and we can run the script in the Terminal
by executing it directly with "node".
Now, instead of fetching a list of reviews
we want to get a single one,
and each entry in the CMS has an "id".
We can use that "id" in the URL,
by requesting "/reviews/8" for example.
Let me comment out all these parameters for now,
and if we go and send the request.
You can see that the "data" in the
response is no longer an array,
but a single review object.
Now, the problem is that
in our pages we don't actually
know the review "id".
We only have the "slug", like "hades-2018",
that's what we get as the dynamic
route param in Next.js.
So, we cannot get a single review by "id".
We'll need to keep requesting a list of entries,
but then use "filters"
to select only the entry with the right "slug".
The way filters work in Strapi is that
we can pass an object with conditions
to apply to this field.
One condition is "$eq", which means "equals".
So we can say "slug" equals "hades-2018".
And this should return only that specific review.
You can see that "data" is again an array,
because we requested an endpoint that
can return multiple entries,
but in this case the array
contains a single element,
that is the review with the "slug" we specified.
In fact, the "pagination" values also show that
there's just one entry in total
that matches our filters.
So this is how we can fetch
a review given its "slug".
Now, we'll still want to select
only the fields we need.
But for the ReviewPage we'll also need the "body",
and we'll still want to populate
the "image" relation.
We don't need to sort, because
we expect a single result.
As for the "pagination" settings,
by default the response includes a "total" count,
but we know there will always be 1 entry at most
that matches any given slug.
So we could pass "pageSize: 1"
and also set "withCount: false",
that disables the "total" count.
This is just a small optimization,
because calculating the total probably requires
a separate query to the database.
Anyway, if we test our script again
we now get only the fields we selected,
and, in the pagination, there
is no "total" any more.
Ok, this is the API response we need.
We can now use the same fetch request
in the "getReview" function.
Let's go and restart the dev server,
by running "npm run dev".
And I'll show the browser again.
We're now ready to rewrite
this "getReview" function.
Actually, before we do that,
the ReviewPage also uses "getSlugs",
in addition to "getReview".
If you remember, "getSlugs" is used
by "generateStaticParams",
to make Next.js generate static pages
for all the available reviews.
Let's comment out this "generateStaticParams"
for now.
This page will still work fine in the dev server;
it's only when building for production
that we want to generate static pages.
This way we don't need to worry
about "getSlugs" for now,
we can reimplement only "getReview" first.
And we'll continue with that in the next video.