Now let's make this a bit more complex.
What if I don't just wanna have my load feedback button here
but I also want to have a let's say /feedback route here
so not /api/feedback but just /feedback.
Which should load a new HTML page.
So a page rendered in the browser
which also lists my feedback.
So now I wanna add a new normal page, not an API route
but I wanna add a new normal page.
That is still possible.
We can still add a feedback JS file here as well
in the pages folder, but outside of API
or as you learned ,alternatively, add a feedback folder
with a index JS file in there.
That's the equivalent to having a file named
feedback JS on the level above.
And that's therefore what I'll go with here
and then in this index JS file
instead of that feedback folder,
we can again create our regular component
the feedback page component which we export
and then here we can of course also render our list of
feedbacks.
And we can now of course also just fetch our feedback data
whenever that component is rendered, for example,
with help of useEffect
to implement client's site data fetching
as you learned it in the data fetching section
but maybe we also wanna pre-render this page
and prefetch the data for pre-rendering.
And that is something which we would do
by exporting an async function called getStaticProps.
That's what you also learned before in this course.
We can still use these features
even if we also use API routes in the project.
Of course, I would say because using API routes
is an extra feature
it doesn't change the way next JS works.
So we can still add regular pages with features like
getStaticProps to also have some
server-side or node JS code
that is executed there when this page is pre-rendered.
Now, the interesting thing is though
what if we now here want to fetch our feedback data
for pre-rendering this page?
So here through props in this component I expect to get
my feedback items let's say and I wanna map them
into list items
where I then still output item.text
and where I then still have my key set to item.id.
But now feedback items should be received through props
with help of getStaticProps.
How can we now make that work?
Well, we did see similar examples
in the data fetching sections.
There we for example, also talked to Firebase
and we then use the fetch API here, the fetch function
here inside of getStaticProps to still send the request
to an API and get data from there.
And that works as you saw there.
But, whilst this is
absolutely fine for external APIs
like the Firebase API, you should not
use fetch inside of getStaticProps or
getServerSideProps to talk to your own API.
Instead since this is all part of one project
and therefore ultimately all served by one server.
What you should do instead
is write any note JS logic that should execute here
directly inside of getStaticProps.
So if we have some logic in our API route
which also might need to be executed here
inside of a regular page,
then we should just make it available through an export
so that we can run the code to find in the API route
directly here inside of getStaticProps
or getServerSideProps.
So that means that here in this case
this code for building the feedback path
and extracting the feedback
should be executed directly here in getStaticProps.
We just don't wanna set some response status code
and return a response
because that's not what getStaticProps is about.
This is just about producing the data
for our page component.
But since I already have extract feedback
and filled feedback path in separate functions
we can just export these functions to make them available
outside of this API feedback JS file
export both functions and then in index JS,
we can import these functions.
We can import from going up one level diving into API
diving into feedback and import from there.
or we put those functions into a separate
other folder and file, right from the start.
We could add a helpers folder on the root project level
and store our functions in some file in there.
That would also be fine.
But here I'm importing from the API feedback file
and I'll import the build feedback path function
and the extract feedback function.
Now, the cool thing is
that next JS will detect that what we're importing here
isn't the end code that will only use inside
of getStaticProps
and therefore that code will still not be included
in the client side bundle.
I talked about this in earlier sections already.
Code used in getStaticProps and dependencies used in there
so imports used in there will not end up
in the client side code bundle if we're not using that code
anywhere in our client side code.
So therefore here
We can now call build feedback path to construct our
file path here.
And then we can get access to our data
by calling extract feedback and passing in the file path
and then we just return our standard object
with the props key as we always do it in getStaticProps
and we expose our feedback items
because that's what I'm looking for.
All my props here, which is my data
because to date I'm extracting is that extracted error
from feedback json.
So now we have that code here inside of our regular page
instead of using fetch and sending a request
to our own API route
because when working with your own API routes
and when requiring them in your regular pages
you should not send the HTTP request to them
but instead leverage the fact that it's all running
on the same computer on the same server
and therefore just import it and directly run that code
instead of sending that unnecessary HTTP request.
And with that if we save all of this
and I visit my domain /feedback
you see that as all to showing up there.
And if we viewed a page source
we see that it was pre-rendered
because of getStaticProps.
So that is how you should interact with your API routes
when you're using that data for pre-rendering a page.
No matter if you're using getStaticProps
or getServerSideProps.