use(props.params) vs useParams() in Client Component in Next.js
What is better and more ideal in Next.js 15? Does using a different one make any difference?
On Server Components the await props.params seems to be the way to go but on Client Components...
I kinda tend on using useParams() to save a render but I'm not so sure about that.
Any advice here? Im sure both work fine but I'm just curious in what works better.
Solution:Jump to solution
Unless you dig into the implementation details of “useParams()” you’ll see if it saves a render or not, maybe it’s implementing the same logic under the hood and they literally work the same, but who knows.
Also, a rerender isn’t much of a problem, it’ll just commit once which is the heavy duty for the browser most of the time, re-render doesn’t mean “re-create the DOM elements” it means “just read the component logic again and decide whether or not to commit again”, and it might not commit again since it’s the same tree… unless it’s not the same tree due to the implementation details of the “useParams()” hook...
11 Replies
I think useParams() is the more ideal and future-oriented choice for Client Components in Next.js 15
Ok, thank you, why though?
Either is fine, whatever works for you. I would go with
useParams() as well, just because the function call is more explicit.I don't know man I just thought 😆
I agree, both should work, but useParams is more clear, so the code is slightly more readable, in my opinion
Ok guys, thank you, but there is no benefit like saving a render or something? I think use() definitely rerenders the page, right?
Solution
Unless you dig into the implementation details of “useParams()” you’ll see if it saves a render or not, maybe it’s implementing the same logic under the hood and they literally work the same, but who knows.
Also, a rerender isn’t much of a problem, it’ll just commit once which is the heavy duty for the browser most of the time, re-render doesn’t mean “re-create the DOM elements” it means “just read the component logic again and decide whether or not to commit again”, and it might not commit again since it’s the same tree… unless it’s not the same tree due to the implementation details of the “useParams()” hook
And I would even say useParams is better. Passing the promise from the server component to the client component involves a network boundary, which is “invisible” to us but data must move between the server and the client through the network.
The useParams() must implement its internal logic in an optimal way since it was especially created for that purpose
That's true, didn't think about that
Thank you, makes sense