How to avoid prop drilling in App Router (Best practice)
Answered
Japanese flying squid posted this in #help-forum
Japanese flying squidOP
I have been wondering about what's the best practice to avoid prop drilling with the new App Router approach.
Let's focus in this example:
- I need to call an endpoint (in server component) to populate all my client components. Let's say that the data is immutable:
What if I want to send the results of the API call to the Client Component D? The data is immutable, and in that case, the best practices say (as far as I know) to not use a state management tool to store the results of the endpoint.
How can I avoid prop drilling? (Pass the result from a Server Component, all the way into the Components A, B, C, until reaching the Component D?
Let's focus in this example:
- I need to call an endpoint (in server component) to populate all my client components. Let's say that the data is immutable:
Server Component (API call)
Client Component A
Client Component B
Client Component C
Client Component DWhat if I want to send the results of the API call to the Client Component D? The data is immutable, and in that case, the best practices say (as far as I know) to not use a state management tool to store the results of the endpoint.
How can I avoid prop drilling? (Pass the result from a Server Component, all the way into the Components A, B, C, until reaching the Component D?
9 Replies
Server component pass value to a react context
Then client component D inside that context can consume the context
Japanese flying squidOP
Yeah the use of a context would be indeed a good solution. There is also an other approach wich is:
Adding a Server component that will be like a wrapper to send data to Client Component D:
The Server Component B can have the data if we use a composition pattern. But every Client Component need to have children props.
This video explain this approach: https://www.youtube.com/watch?v=rbTzTXHkXA8
I'm just not sure if this is a better approach over the use of a context performance-wise. Also it does not seems to be a common practice.
Adding a Server component that will be like a wrapper to send data to Client Component D:
Server Component A (API call)
Client Component A
Client Component B
Client Component C
Server Component B
Client Component DThe Server Component B can have the data if we use a composition pattern. But every Client Component need to have children props.
This video explain this approach: https://www.youtube.com/watch?v=rbTzTXHkXA8
I'm just not sure if this is a better approach over the use of a context performance-wise. Also it does not seems to be a common practice.
@Japanese flying squid Yeah the use of a context would be indeed a good solution. There is also an other approach wich is:
Adding a Server component that will be like a wrapper to send data to Client Component D:
`Server Component A (API call)
Client Component A
Client Component B
Client Component C
Server Component B
Client Component D`
The Server Component B can have the data if we use a composition pattern. But every Client Component need to have children props.
This video explain this approach: https://www.youtube.com/watch?v=rbTzTXHkXA8
I'm just not sure if this is a better approach over the use of a context performance-wise. Also it does not seems to be a common practice.
Nextjs already use a bunch of contexts behind the scenes, so adding one more context is not going to harm your bundle size disastrously. So choose the solution that would be the most readable and maintainable in the long run
In your case as Joulev rightfully explained you need a client context, it won't have any performance impact if data are not mutable and works exactly as you want
Japanese flying squidOP
Thank you guys, I will close the thread 💪