我对复杂的、数据驱动的 UI 的整体架构有些怀疑。以带有侧边栏、标题和徽标的常见博客页面为例,其想法是:
在现实世界中,当我构建这个时,它宁愿是这样的:
最后,我页面上的所有内容都受到某种用户交互或用户诱导状态的影响。我无法想象我在过去几年中构建的 UI 仅以隔离的方式加载静态内容。
我唯一想到的是,对于 SEO,我可以通过服务器端组件加载一些数据驱动的 HTML 作为骨架,以便 SE 机器人可以立即读取数据,然后在准备好后使用交互式客户端等效项进行显示。不确定是否可以使用
<Suspense />
我可能需要阅读一些内容。
否则,对于上述用例,我是否遗漏了一些东西?除了数据获取之外,我根本无法想到服务器端组件的现实用例,因为我页面上的每个项目都将始终受到用户交互的影响(因此:用户界面)。
感谢您的任何澄清:)
NextJs 应用程序路由器文档中有一篇关于此的很棒的文章。
TLDR: 你是对的。在像您所描述的基于博客的系统中,服务器组件的大多数用例都是数据获取。
就我个人而言,我们构建的系统具有很大的依赖性和我们保留在服务器端的数据获取令牌。这显着减少了客户端的加载时间,并提高了安全性。在某些情况下,它还允许我们绕过编写 REST api,而直接查询数据。
用于切换侧边栏的简单状态管理似乎并不能真正从服务器端受益。它不会出现大的依赖性问题,或者最好保持私有的私有令牌等。正如我之前所说,我同意您的分析,即您的用例不会从 SSR 组件中受益匪浅。
话虽这么说,平行路线有很大的潜力。这将允许您仅使用 SSR 组件在同一 URL 上切换布局、徽标或其他内容。如果您正确构建应用程序,则只有“控制器/切换器”组件需要成为客户端,其余部分可以是 SSR。 (目前尚不清楚这是否真的会提供很大的性能优势,除非您静态地预渲染所有 SSR 并使用缓存)
我相信您已经意识到这一点,但您还可以选择将 SSR 组件呈现为 CSR 组件的子组件,这将允许您更动态地选择如何构建项目。