我对 React Server Components 是持保守态度的,正如 RFC 中大部分同学说的,它可能并没有像 Hooks 那样解决了我们业务中实际的问题。而且该方案本身还有大量的问题需要解决,方案引入成本非常高。
可能带来的问题我认为会有以下几点:RSC 把 JS 打包体积的成本转移到了 API 上,对于同组件但是不同数据的场景(例如分页场景)会带来一定的响应劣势。
客户端执行向上转移导致了服务器成本增加,这和为了降成本现在狂推 Serverless 的大潮流是冲突的。另外它还会带来接口响应时间的变慢,对性能有高要求的场景肯定无法适用。
官方也提到 RSC 会有很大的心智负担,Server Component, Client Component, Shared Component 如何更好的划分组件成了写组件之前让人头疼的问题。同时多端导致的调试问题也会造成一定门槛。
总的说来官方提出的问题可能是问题,但是可以有其它的轻成本方案去解决,而不是引入这种超重成本的方案。瀑布流的问题可以通过修改组件的写法或者使用 GraphQL 解决,格式化数据引入了不必要的打包组件可以通过接口预先格式化好数据解决。
不过我认为 RSC 也是有亮点的,我个人认为它相当于带来了 React 组件序列化的官方标准。为多端、多机、多语言之间实现 React 组件交流提供了基础。基于这套序列化方案,我们可以实现组件缓存存储,多机器并发渲染组件等。通过这套序列化标准让其它语言去实现 React 组件也不是没有可能。
可以查看文章了解详细:怡红公子:React Server Component 可能并没有那么香zhuanlan.zhihu.com