初探 RSC

大家好，我是一百个Chocolate。

近段时间，我一直在看关于 RSC（React Server Components） 的内容，今年夏季社区讨论也挺多的，我也阅读了挺多社区大佬的文章，但毕竟现在还算是新玩意，业界以 Next.js 这个框架实践为主。

我现在其实一直处于观望阶段，Next.js 13 后出的 App Router 目前还没开始完全落地使用，不过倒是看了一些博主的视频，大概知道其中的规范。

这次呢，我就先大概梳理一下近段时间我所了解的关于 RSC 的内容，我个人感觉是在学「设计模式」一样，但业界提供的书写规范，比如 use client 这样以后会保留吗？

同样，我也看到一些博主对于新的规范也有各种吐槽，一用就报错之类的，毕竟以前用 React 其实就像写多个函数一样，现在呢要进行拆分，并且已经有了规范，我原来引入方式习惯要改正了。

由于社区内感觉还没到达非常统一的版本，那么，这次我就来简单分享一下我所了解到的 RSC。

你所使用的 React 是？

Dan 神对于 RSC 写了挺多很好的解释内容，如下面这篇文章：

https://github.com/reactwg/server-components/discussions/4

他画了两张图，言简意赅，第一张是大多数人所了解的 React：

你会发现这张图，诶，怎么左边是空的呢，为什么不把图放中间呢是吧。

其实这是故意这么做的，我们来看下一张：

那么对于 React 而言，RSC 的引入其实并没有改变你原来的心智模型。而是多增加了一层服务端的树。

那么从这个图也就大概知道了，你所使用的 React 还是那个 React，只是你也可以选择性的去使用 RSC。为了消除歧义，Dan 在上图做了一些修改，如下：

也就是将你大多数人了解的 React 那部分改为 Clien Tree，也就是客户端的功能。

那么这就很好的解释了该篇文章的主题：为什么客户端组件能够用 SSR 方式转换成 HTML？

因为我们过去使用的 React 其实都可以成为客户端组件，以前就能用 SSR，现在依旧还是能用。

只不过服务端组件（RSC）出来了之后，多了一种方式。

为什么要有服务端组件呢？

上文大概讲述了是什么，下面我们来梳理一下为什么要有 RSC 这玩意呢？

主要是参考这篇文章：

https://www.perssondennis.com/articles/why-server-components-a-brief-history-of-web

这篇文章还是比较深度的，内容也比较长，基于上述疑问只讲述部分内容，其它感兴趣的可以阅读一下原文，还是挺不错的。

其实前端渲染方式还是有挺多变化的，从早期没有前端概念，基本上都是在服务端一起渲染了，到后面 SPA 普及，也出现了 SSR、SSG、ISR 这样的渲染方式。

再到目前讨论火热的 RSC，看似回到了以前服务端都一起渲染的方式，但实际还是有一点差别的。

像 SSR 方式，就是将内容转换成 HTML，然后对于可交互的部分，还是发送一个 js bundle 在客户端执行，也就是常说的 hydration。

然而 RSC 出来，与 SSR 有点区别的是我不是直接转换成 HTML，而是一个真正的 React 组件，可以在服务端执行，并且需要操作数据库的尽量都在我这里执行，而不是前端再 fetch 请求了，过去 React 18 引入了 suspense 以及并发概念，在客户端请求的时候可以加上 loading 效果，vercel 博客里面有一篇讲的特别好，如下：

https://vercel.com/blog/how-react-18-improves-application-performance

感兴趣可以深入了解一下。

给我个人感觉就是 RSC 出现，一些操作数据库的逻辑几乎都写在了 RSC 里面，可以说我们原本以为的 React 写法里面可能真的不需要 useEffect 了。

关于 useEffect 这个话题，在 react.dev 这个新版文档里面也有相关内容，这可是官方觉得你真的不需要：

https://react.dev/learn/you-might-not-need-an-effect

那么，下面来提炼一下使用 RSC 的一些优缺点。

优点：

1. 服务器到数据库的网络延迟通常比客户端低，客户端减少一些请求，并且可直接将服务端组件内容快速渲染。
2. 初始渲染和 SEO 会更好，这个和 SSR 道理类似。
3. 可使用一些 API 密钥之类的，这些一般不能在客户端组件使用。
4. 相对来说，在服务端请求也会更安全一点。
5. 使用 RSC 的话就不需要在前端添加 loading 和骨架屏之类的效果了。
6. 像 Next.js 里对于 RSC 还内置了 fetch，可以让请求进行缓存，如果需要更新操作的话，还引入了 server action 概念。
7. ...

缺点：

1. 关键看数据处理这块，也许对服务端负载更高一点，也就会有更多的服务器的开销。
2. 目前 RSC 算是比较新，社区内关于 RSC 的库其实支持还不算很多，这也得推动社区生态发展了。
3. ...

关于第三方库这里，我最近也看到了有个帖子，如下：

https://github.com/reactwg/server-components/discussions/6

这里面例举了目前支持 RSC 的一些库，可以收藏起来看看，看是否会真的让社区生态也跟随，或者今后有新的变化之类的。

1. 目前 RSC 还不够完美，我开头其实也说了，比如 use client 这样的写法，以及服务端组件在客户端组件使用的话需要作为 children 传递过去，然后一下这里是客户端一下那里又是服务端，如果对于 RSC 知识掌握不够充足的话，写起来出现一堆报错，不方便快速使用。

如何体验 RSC？

以上说了这么多，那么如果去使用 RSC 呢，目前社区内还是以 Next.js App Router 为主，可以先掌握这一块。你是否真的需要 RSC，其实看 Dan 神画的那几张图就明白了，是可选的，你还是可以选择最原汁原味的 React 用法。

而如果你是在使用 Next.js 的话，App Router 也不是目前必须要使用的，官方也提供了详细的迁移方方案。

那么对于老项目的话，官方其实也明白迁移成本有点高，不过推荐的是能够渐进式地迁移，也就是 Pages 和 App Router 可以共存使用。不过个人觉得迁移太麻烦了，折腾起来也挺费劲的，不妨新项目直接尝鲜就好。

总结

以上就是我对于 RSC 的一些初步探索，大概是这些内容，其实还有更深度的内容，只是我目前觉得去输出技术内容准备还不够充足，我只是达到一个掌握状态，知其所以然。

目前依旧还是以吸收业界大佬们的观点和经验为主，毕竟这玩意到达普及还需要一段时间，不过可预见的是这种体验还是很棒的，前端页面给人一种很丝滑的感觉。

也许本文会有一些不足或者内容表述方面有误，欢迎指正，下期见。