Next.js的诸多特性(比如Server Action、App Router),都是在RSC(React Server Component)基础上衍生出的。从名字可以看出,RSC是React的特性。那么,该怎么理解RSC和Next.js的关系呢?
React团队的宿愿
对于前端框架的开发范式,有三个重要衡量因素:
1.用户体验
2.维护成本
3.性能
但是,通常很难做到三者兼顾(具体原因本文不细究,感兴趣的同学可以看data-fetching-with-react-server-components。简单来说,在前端开发中,「IO瓶颈」是影响内容渲染速度的重要因素(可以简单理解为,前端需要等待请求返回数据后,再根据数据渲染内容,这期间延迟的时间就是「IO瓶颈」)。
但是,前端框架能够掌控的范围局限在前端,所以无法对「IO瓶颈」做出极致优化,只能在三个因素中做出取舍(比如考虑用户体验与性能时,代码维护成本就高)。React团队为了同时兼顾三者,需要对服务端拥有更多掌控。这就是RSC诞生的初衷。但是,大部分React的受众只是把React当作前端view库,并不会直接使用RSC相关功能,所以React团队选择和Next.js团队合作,落地RSC。
此时我们发现,React有三类受众:
1.普通前端开发者,用稳定的React做业务开发
2.其他合作团队(比如Next.js团队),React团队为他们提供API支持
3.喜欢尝鲜的开发者/团队,愿意尝试那些可能出现在未来版本中的特性(通常还不稳定)
React团队针对这三类受众,制定了三条版本迭代路径:
1. Latest路径
2. Canary路径
3. Experimental路径
我们正常通过npm i react下载的React包就是「Latest路径」的打包产物。通过npm update react@canary可以替换为canary包,RSC相关的功能就属于canary包。
同理,通过npm update react@xperimental可以替换experimental包。
脱离Next.js使用RSC
在Next.js的App Router模式,所有组件默认为服务端组件(即在服务端render的组件),只有当组件所在文件顶部标记了'use client'指令时,该组件是客户端组件(即在前端render的组件)。
比如下面就是个客户端组件:
'use client'
import {useState} from 'react';
function Cpn() {
const [num, update] = useState(0);
// 堆代码 duidaima.com
// ...省略
}
实际上,这并不是Next.js自己的定义,而是RSC中的规范。在React文档中,我们可以看到'use client'与'use server'规范的定义,其中:
'use client'用于标记客户端组件(在服务端,默认所有组件都是服务端组件,所以客户端组件需要专门标记)
'use server'用于标记前端的某个函数为Server Action(可以在前端执行的服务端逻辑)
既然是规范,那就需要落地。在Next.js中,规范的落地都被收敛到Next.js框架内部实现了。如果要脱离Next.js使用RSC,就需要我们自己落地规范。
RSC规范的落地包括三部分:
1.服务端编译时
2.服务端运行时
3.客户端运行时
这三者都被收敛到react-server-dom-webpack包中。接下来我们简单讲下这三部分的作用。
服务端编译时
通过react-server-dom-webpack/plugin名字中的webpack、plugin字样能看出,这是个webpack插件,配置类似如下:
const ReactServerWebpackPlugin = require("react-server-dom-webpack/plugin");
const config = {
// ...省略其他配置
plugins: [
new ReactServerWebpackPlugin({ isServer: false }),
],
}
他的作用是识别项目中的'use client'指令,作用有些类似于「全自动React.lazy」。使用过React.lazy特性的同学会知道,当我们通过React.lazy懒加载组件时,懒加载的组件会被打包工具(比如webpack)打包成独立的chunk。当前端需要该组件时,会通过Jsonp请求chunk文件。
比如下面代码中的./Cpn.jsx组件由于懒加载,会被打包成独立的chunk:
import React from 'react';
const LayCpn = React.lazy(() => import('./Cpn.jsx'));
function App(props) {
return <LayCpn {...props} />;
}
与React.lazy类似,当我们在组件所在文件的顶部标记'use client'时,并在服务端组件的子孙组件中使用到该组件,该组件代码也会打包成独立的chunk。由于这个过程是全自动的,所以可以称为「全自动React.lazy」。
服务端运行时
上面讲到的编译产物都是「客户端组件对应chunk」,所以他们是不会在服务端运行时使用的。服务端运行时的作用类似SSR,都是给定JSX输入,经过render后获得输出。比如,给定如下输入:
function App() {
return <div>hello</div>;
}
对于SSR,会获得字符串'<div>hello</div>'的输出。对于RSC规范,将输入传给react-server-dom-webpack/server导出的renderToPipeableStream方法,会获得如下序列化数据:
0:"$L1"
1:["$","div",null,{"children":"hello"}]
再让我们看一个稍微复杂点的例子:我们有个组件Cpn,由于他包含客户端状态(使用了useState),所以只能作为客户端组件(顶部标记'use client'):
'use client'
import {useState} from 'react';
function Cpn() {
const [num, update] = useState(0);
// ...省略
}
现在,我们的服务端组件App返回值中包含了Cpn:
function App() {
return <div><Cpn/></div>;
}
经由renderToPipeableStream方法,会获得如下序列化数据:
0:"$L1"
2:I["./src/app/Test.jsx",["client0","client0.chunk.js"],"Test"]
1:["$","div",null,{"children":["$","$L2",null,{}]}]
可以发现,序列化数据中并不包含具体的客户端组件代码,而是组件代码对应的文件(client0.chunk.js),这个文件就是我们在「服务端编译时」打包产生的chunk文件。
客户端运行时
当「服务端运行时」产生的「序列化数据」传递给前端时,react-server-dom-webpack又出场了,这次使用的是react-server-dom-webpack/client。这个包提供了几个方法,用于将「从不同数据源获取的序列化数据」转换为「合法的React Element」,比如:
createFromFetch:通过fetch方法获取序列化数据
createFromReadableStream:通过可读流获取序列化数据
对于上述序列化数据:
0:"$L1"
2:I["./src/app/Test.jsx",["client0","client0.chunk.js"],"Test"]
1:["$","div",null,{"children":["$","$L2",null,{}]}]
经由react-server-dom-webpack/client中方法的转换,会得到一个React.lazy组件,这样前端的React就能正常render这个组件了。
总结
RSC规范属于React特性,来自于React Canary。规范的落地可以通过react-server-dom-webpack包实现。
整个工作流程包括三个阶段:
服务端编译时,对应react-server-dom-webpack/plugin
服务端运行时,对应react-server-dom-webpack/server
客户端运行时,对应react-server-dom-webpack/client
在Next.js中,RSC规范的落地被集成到框架内部,做到了开箱即用的RSC,并在此基础上衍生出更完善的功能(App Router)。