Should we avoid hooks in nextjs?
Answered
Brown bear posted this in #help-forum
Brown bearOP
Hi, I am a react developer and recently started working in a team of nextjs devs.
To my understanding server purpose is to get the initial page load and then client should handle ui updates, like changing lists and stuff,
So I was doing the initial data fetch in server components and passing to a client component which was marked with 'use client' and it uses hooks and state is initalized with data from server.
But the nextjs devs keep telling me this is bad and we should avoid hooks because this is bad for server optimization, what this even means?
To my understanding server purpose is to get the initial page load and then client should handle ui updates, like changing lists and stuff,
So I was doing the initial data fetch in server components and passing to a client component which was marked with 'use client' and it uses hooks and state is initalized with data from server.
But the nextjs devs keep telling me this is bad and we should avoid hooks because this is bad for server optimization, what this even means?
Answered by LuisLl
Before Server Components every react app used Client Components lol, even Next.js.
Maybe best would be to set some ground rules on when and when NOT to use client component at the team level lol, and try to define what’s best for your project.
Not because RSC are the new shiny thing that means they can solve all the problems, and when you try hard to find a way to solve the problem on the Server side, later you just realize you reinvented the wheel for a problem that had a well accepted solution on the Client side.
Maybe best would be to set some ground rules on when and when NOT to use client component at the team level lol, and try to define what’s best for your project.
Not because RSC are the new shiny thing that means they can solve all the problems, and when you try hard to find a way to solve the problem on the Server side, later you just realize you reinvented the wheel for a problem that had a well accepted solution on the Client side.
13 Replies
You should ask them what they actually mean because using hooks is Next.js is completely valid. I can somewhat sympathize with them and suggest you only make use of client components when you absolutely need it.
Maybe they’re saying you do not need to have client components taking initial data from the server in and putting it in useState if all you do is render what you got passed from the server, in these cases where you do not require interactivity it’s better to keep the UI output on the server too.
On the other hand, If your client component exist because you need interactivity, and you need them to re-render because of this interactivity, or you need browser APIs, then “use client” is the only way.
If you can leverage the server to also produce React Components you should do that, this way you will only be shipping their output to the browser (React Server Component payload), instead of sending the JavaScript needed to re-build the react component on the client, which happens when you mark them with “use client” and should be used exclusively when you need these components to “hydrate” on the browser
Maybe they’re saying you do not need to have client components taking initial data from the server in and putting it in useState if all you do is render what you got passed from the server, in these cases where you do not require interactivity it’s better to keep the UI output on the server too.
On the other hand, If your client component exist because you need interactivity, and you need them to re-render because of this interactivity, or you need browser APIs, then “use client” is the only way.
If you can leverage the server to also produce React Components you should do that, this way you will only be shipping their output to the browser (React Server Component payload), instead of sending the JavaScript needed to re-build the react component on the client, which happens when you mark them with “use client” and should be used exclusively when you need these components to “hydrate” on the browser
To my understanding server purpose is to get the initial page load and then client should handle ui updates, like changing lists and stuff.You are correct, what they might be suggesting is that if the list will change due to a mutation to a database (which needs network request) to later retrieve the fresh data, this operation could stay on the server and what will happen is you’ll request the new page with the latest data instead of mutating your client state to append a new item to the list. Idk if this was clear enough from my side, let me know if you need clarification
@LuisLl > To my understanding server purpose is to get the initial page load and then client should handle ui updates, like changing lists and stuff.
You are correct, what they might be suggesting is that if the list will change due to a mutation to a database (which needs network request) to later retrieve the fresh data, this operation could stay on the server and what will happen is you’ll request the new page with the latest data instead of mutating your client state to append a new item to the list. Idk if this was clear enough from my side, let me know if you need clarification
Brown bearOP
hey thnx for the reply, I understand what you mean, but isn't it more expensive if the server has to return the whole page again instead of just removing the item on client side? The server is used by multiple users but the client state doesn't matter, I mean you still have to send a request which should be processed by server, but at least server doesn't have to render the page again
I see what you mean, it depends on the tasks you’re performing on the client side, if we are talking about filtering a list, for example, we know for a fact that this can be solved on the client side by mutating a state. Especially if the initial data coming from the server is only ever fetched once, and the filters don’t require to fire new network requests because they work locally.
Usually what you try to avoid is the client-server network roundtrip. But if the request is going to be made anyway, the server processes requests faster than the client.
Usually what you try to avoid is the client-server network roundtrip. But if the request is going to be made anyway, the server processes requests faster than the client.
For many cases the client is needed, and the client has the problem solved and that will continue to be relevant even with server components.
Brown bearOP
Another thing to move the client boundary to the leaves this causes a not so reusable component for example if you have a product card component and you want to keep everything server side but for the Add to cart button you create a client component that handles the logic to add product to cart so that you avoid passing onAddToCart prop, isn't this against the idea of react itself
React is all about composition, it’s always been. It just happens to be more things to consider now to make a decision on how to compose
Whatever works for you for the specific case that’s valid, idk if your coworkers have a wrong idea about client components.
Or maybe you have to ask them what they meant to say exactly.
Something I would strongly recommend tho, is that your files
Or maybe you have to ask them what they meant to say exactly.
Something I would strongly recommend tho, is that your files
layout.tsx and page.tsx should be kept Server Components, adding “use client” at the top is somewhat considered a bad practice because you’re gonna lose the Server features (metadata, data fetching, rendering strategies, etc). For the rest of components just mix and match whatever patterns work for youBrown bearOP
we are building an e commerce and these guys just idk, what are they thinking whenever they see 'use client' they are scared to death, I don't understand why lol, I think it's time to either let me do my thing or I will quit this project
Before Server Components every react app used Client Components lol, even Next.js.
Maybe best would be to set some ground rules on when and when NOT to use client component at the team level lol, and try to define what’s best for your project.
Not because RSC are the new shiny thing that means they can solve all the problems, and when you try hard to find a way to solve the problem on the Server side, later you just realize you reinvented the wheel for a problem that had a well accepted solution on the Client side.
Maybe best would be to set some ground rules on when and when NOT to use client component at the team level lol, and try to define what’s best for your project.
Not because RSC are the new shiny thing that means they can solve all the problems, and when you try hard to find a way to solve the problem on the Server side, later you just realize you reinvented the wheel for a problem that had a well accepted solution on the Client side.
Answer
Brown bearOP
I think I will just have to ignore, they are not giving me anything concrete and reasonable that I should follow
Well just know you’re not wrong by using client components, as long as they make sense and you can still leverage the server to provide the initial data, you’re fine.
If they wanna follow specific practices to keep everything on the server then the only way is that they share how so project stays consistent 👍 good luck
If they wanna follow specific practices to keep everything on the server then the only way is that they share how so project stays consistent 👍 good luck
Brown bearOP
Thanks man, cheers