NextJS Learn Chapter 11 - Why is it better to do a full server render every time the search is used?
Unanswered
Orinoco Crocodile posted this in #help-forum
Orinoco CrocodileOP
I am going through the Chapter 11 of the Next JS course, and I have a question regarding the new model with server side rendering as I am trying to figure things out in my head.
Relevant tutorial section - https://nextjs.org/learn/dashboard-app/adding-search-and-pagination
Relevant github code for the question - https://github.com/vercel/next-learn/blob/main/dashboard/final-example/app/ui/invoices/table.tsx
First of all, the usage of query params for managing state for the search query and the page is absolutely awesome, definitely something I will be keeping in mind.
My question in a very short form is: Why do we want the <Table> Component to be server side rendered? I am not talking about the fetch of the invoices, but about the actual HTML. Going to explain what I mean below.
On the initial request of the page, I get it, things are going very good, we are fetching the invoices on the server, we are rendering the html on the server, the client doesn't receive any js for this component, only sees html, this is brilliant.
My question is around why this model is good when someone searches something. From what I understand, when someone searches, basically we get a network call towards the server in order to do 2 things: 1. Query the DB for invoices, 2. Render the HTML and then we send the HTML back to the client. This to me sounds bad because we are regenerating the html on the server on absolutely every search of the user. Below I am explaining a different way of doing it (which is probably wrong but currently in my head feels better).
Continued...
Relevant tutorial section - https://nextjs.org/learn/dashboard-app/adding-search-and-pagination
Relevant github code for the question - https://github.com/vercel/next-learn/blob/main/dashboard/final-example/app/ui/invoices/table.tsx
First of all, the usage of query params for managing state for the search query and the page is absolutely awesome, definitely something I will be keeping in mind.
My question in a very short form is: Why do we want the <Table> Component to be server side rendered? I am not talking about the fetch of the invoices, but about the actual HTML. Going to explain what I mean below.
On the initial request of the page, I get it, things are going very good, we are fetching the invoices on the server, we are rendering the html on the server, the client doesn't receive any js for this component, only sees html, this is brilliant.
My question is around why this model is good when someone searches something. From what I understand, when someone searches, basically we get a network call towards the server in order to do 2 things: 1. Query the DB for invoices, 2. Render the HTML and then we send the HTML back to the client. This to me sounds bad because we are regenerating the html on the server on absolutely every search of the user. Below I am explaining a different way of doing it (which is probably wrong but currently in my head feels better).
Continued...
1 Reply
Orinoco CrocodileOP
What if we split this component in 2 components. Container component which is a server component which is in charge of fetching the invoices for the first render, and a children component inside which is client component which renders the HTML and also has the ability to refetch the invoices at a later point in time. I get it on the first render we are not as good as the other scenario, because we are only fetching the data on the server, but we are generating the html on the client which means that the user needs to receive the js for the page. But if we do that, on every user search usage, we just do a network call to the server to fetch the new invoices, but we are re-rendering the html on the client.
Basically my issue is why is it better to regenerate the full html on the server on every search usage, instead of simply refetching the data needed and re-rendering on the client. Again, I understand that on the initial page load the user needs to receive JS in order to make the first render happen, but this still seems like a better thing that re-rendering the full html on the server on every search.
Looking forward for all of your oppinions. Thank you!
Basically my issue is why is it better to regenerate the full html on the server on every search usage, instead of simply refetching the data needed and re-rendering on the client. Again, I understand that on the initial page load the user needs to receive JS in order to make the first render happen, but this still seems like a better thing that re-rendering the full html on the server on every search.
Looking forward for all of your oppinions. Thank you!