React 的未来：服务端组件服务端组件是什么？截至目前

文章图片
服务端组件是什么？
截至目前，我们对React组件的了解只是客户端组件，仅此而已。
然而， React团队正在试验一个新的想法，那就是将React组件区分为两个类型：客户端组件和服务端组件。该提案的开头就是使用不同的文件扩展名（.client.js和.server.js）来区分它们。然而，客户端组件和服务端组件到底是怎么定义的？
首先，客户端组件指的就是现在我们日常开发中使用的React组件。其次是服务端组件，从某种意义上来说它是一个新型组件，该类型的组件会在服务端完成渲染后，再发送到客户端。服务端组件哪些优势？
乍一看，服务端组件类似于服务端渲染（SSR），实际上，服务端组件的很多优势和服务端渲染也是很类似：
提供了直接访问服务端资源（如：数据库、文件系统、内部的微服务等）的可能，因此开发起来会更容易。避免了不必要的客户端和服务端之间的交互，因此性能更快允许一些类库可以直接运行在服务端，因此减小了客户端包文件的大小除此之外，服务端组件还给开发过程带来了更好的体验，特别是在代码切割上：
自动代码切割（例如：为了让客户端实现按需加载，需要将代码切割成一个个的小包），目前为了实现这个功能， React开发人员需要手动实现如下代码：

文章图片
未来，服务端组件会自动处理，这就意味着，我们无需特殊代码处理就可以实现此功能：

文章图片
然而，要想真正体会到服务端组件的强大优势，必须将其与服务端渲染（SSR）进行更细致的比对。
那么，服务端组件和SSR有哪些不同呢？
在使用SSR时，你需要先在服务端完成HTML的渲染，然后再将该HTML发送到客户端。然后此过程只会发生在页面的初次访问时（也就是初始化加载的时候）。至此之后，你的React应用在数据更新展示等行为表现上和常规的React应用没有任何区别。在展示更新之后的数据时，都是要么从客户端发送一个网络请求，要么页面整体刷新，但不管采用哪种方式，都会导致组件的二次渲染和状态丢失，从而影响性能和客户体验。
相对而言，在使用服务端组件时，你的组件在服务端完成渲染，然后通过自定义的协议发送到客户端（如下图）。 React拿到数据时，将新的UI整体的合并到客户端UI树里面，此过程不会对客户端其他状态产生影响。此过程可以无限次数的执行。 React通过整体UI模块更新的方式，达到保持客户端状态的目的，极大的增强了用户体验。

文章图片
要了解更多的细节可以参考DanAbramov在推特上的这条回复，或者阅读来着React数据团队的LaurenTan在Twwiter的帖子，或者访问MehulMohan发布在freeCodeCamp上的这篇文章
注意事项
由于服务端组件是静态的、服务端渲染的，因此相对于客户端组件，不可避免的会有些使用限制。
首先，服务端组件不能有任何交互行为（例如：不能使用useState() ， useEffect()）。但是你可以通过在服务端组件内部引入客户端组件（客户端组件是允许存在交互行为的）的方式来解决这个问题。例如下面的示例代码就做到了两者兼顾：

文章图片
其次，由于服务端组件是在服务端完成渲染后通过网络传输给到客户端，因此服务端组件传输props到客户端组件的时候， props必须被序列化（意味着：可传输的数据只能是字符串、JSON对象或者JSX ，不能传输JavaScript函数）。
接下来是什么？
虽然这一切都很令人兴奋，但该功能仍处于实验阶段。它的API和具体实现未来都有变化的可能，因此该特性目前还不能被运用到生产环境。
现在， React团队正在和Next.js团队紧密合作，致力于将服务端组件集成到React框架里。同时这里有个基于内测版本的webpack插件和Parcel插件的访谈。
最后，服务端组件将会是一个可选的特性，现有的React代码依然可以正常工作，因此开发人员不需要急着采用新功能。
想了解更多关于该特性的信息，我强烈建议你观看这个示例视频或者阅读此规范，感谢阅读此文章！