下14/15实际运用：容器组件模式

Question

1. 假设我们在管理 UI 中使用了一个搜索列表视图。 在 vanilla React 中，我的结构是这样的：

// SearchList.tsx .. mapped to route URL

const SearchList = () => {
    /* As a container component, it holds all sources of truth (state, logic, etc.) and only passes props down to its children */
    // ...

    return (
        <div>
            <SearchBox data={...} ... />  /* Presentation component that takes search params and event handlers as props */
            <Grid data={...} ... />  /* Presentation component that receives rowItems and event handlers as props */
        </div>
    )
}

2. 但是，当我将这种建模方法转移到Next 应用程序路由器时，似乎只有真正的静态布局屏幕或不重新获取数据的部分才能成为纯粹的服务器组件。 与应用程序路由器对应的所有 page.tsx 文件最终都会成为客户端组件。

3. 就效率和道具跟踪而言，我仍然认为容器组件模式是最佳的。但现在我怀疑我是否错过了优化优势或导致 JS 包变得太大。当然，客户端组件在某种程度上仍然是服务器渲染的，所以这可能并不重要。但在 Reddit 上，我看到很多争论：人们认为在每个下一页上使用 use client 都达不到目的，而其他人则主要使用客户端组件和客户端数据获取。

4. 对于生产使用，在采用 Next 时，您如何应用组件模式和状态管理？ 您是否将所有状态传递给较低的组件？对于交互频繁的管理或业务界面来说，这种方法似乎很麻烦。任何建议将不胜感激。

Answer 1

对于第二部分，请尝试此处描述的动态渲染服务器组件。

除非你需要使用像

useState

、

useEffect

等React hooks，否则你应该首先考虑使用服务器组件。