- Imagine a scenario where we have a search list view utilized in an admin UI. In the world of vanilla React, I structured it as follows:
// SearchList.tsx .. linked to route URL
const SearchList = () => {
/* Acting as a container component, it houses all sources of truth (state, logic, etc.) and merely passes props down to its children */
// ...
return (
<div>
<SearchBox data={...} ... /> /* Presentation component taking search params and event handlers as props */
<Grid data={...} ... /> /* Presentation component receiving rowItems and event handlers as props */
</div>
)
}
However, upon transplanting this modeling approach into the Next app router, it appears that only genuinely static layout screens or sections which do not refetch data can be pure server components. All the page.tsx files associated with the app router end up being client components.
In terms of effectiveness and prop tracking, my belief in the container component pattern remains steadfast. Nonetheless, I now find myself contemplating if I am neglecting potential optimization advantages or causing Javascript bundles to become bloated. Admittedly, client components are still somewhat server-rendered, so perhaps this concern is insignificant. Yet on platforms like Reddit, there exists much discourse: some argue that utilizing client-side scripting on every Next page contradicts the essence of the framework, while others heavily employ client components and data fetching on the client side.
Upon integrating Next.js into real-world applications, how have you implemented component patterns and state management? Do you funnel all state down to subordinate components? This strategy could seem burdensome for interfaces laden with interactive elements in administrative or commercial settings. Any insights would be greatly valued.