Original subtitles

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.