《第1706期》不只是同构应用<isomorphic 工程

前言

今日早读文章由《React 状态管理与同构实战》作者@LucasHC授权分享

正文从这开始~~

讲道理确实是这样的,但是讲道理你也许并没有真正在实战中领会同构应用的精髓。

同构应用能够实现的本质条件是虚拟 DOM,基于虚拟 DOM 我们可以生成真实的 DOM,并由浏览器渲染;也可以调用不同框架的不同 APIs,将虚拟 DOM 生成字符串,由服务端传输给客户端。

但是同构应用也不只是这么简单,它涉及到 NodeJS 层构建应用的方方面面。拿面试来说,同构应用的考察点不是“纸上谈兵”的理论,而是实际实施时的细节。今天我们就来聊一聊“同构应用工程中往往被忽略的细节”,需要读者提前了解服务端渲染和同构应用的概念。

相关知识点如下:

打包环境区分

第一个细节:我们知道同构应用实现了客户端代码和服务端代码的基本统一,我们只需要编写一种组件,就能生成适用于服务端和客户端的组件案例。可是你是否知道,服务端代码和客户端代码大多数情况下还是需要单独处理?比如:

路由代码差别:服务端需要根据请求路径,匹配页面组件;客户端需要通过浏览器中的地址,匹配页面组件。

来看一个例子,客户端代码:

BrowserRouter 组件根据 window.location 以及 history API 实现页面切换,而服务端肯定是无法获取 window.location 的,服务端代码如下:

需要使用 StaticRouter 组件,并将请求地址和上下文信息作为 location 和 context 这两个 props 传入 StaticRouter 中。

打包差别:服务端运行的代码如果需要依赖 Node 核心模块或者第三方模块,就不再需要把这些模块代码打包到最终代码中了。因为环境已经安装这些依赖,可以直接引用。这样一来,就需要我们在 webpack 中配置:target:node,并借助 webpack-node-externals 插件,解决第三方依赖打包的问题。

对于图片等静态资源,url-loader 会在服务端代码和客户端代码打包过程中分别被引用,因此会在资源目录中生成了重复的文件。当然后打包出来的因为重名,会覆盖前一次打包出来的结果,并不影响使用,但是整个构建过程并不优雅。

由于路由在服务端和客户端的差别,因此 webpack 配置文件的 entry 会不相同:

注水和脱水

第二个细节非常重要,涉及到数据的预获取。也是服务端渲染的真正意义。

什么叫做注水和脱水呢?这个和同构应用中数据的获取有关:在服务器端渲染时,首先服务端请求接口拿到数据,并处理准备好数据状态(如果使用 Redux,就是进行 store 的更新),为了减少客户端的请求,我们需要保留住这个状态。一般做法是在服务器端返回 HTML 字符串的时候,将数据 JSON.stringify 一并返回,这个过程,叫做脱水(dehydrate);在客户端,就不再需要进行数据的请求了,可以直接使用服务端下发下来的数据,这个过程叫注水(hydrate)。用代码来表示:

服务端:

客户端:

这一系列过程非常典型,但是也会有几个细节值得探讨:在服务端渲染时,服务端如何能够请求所有的数据请求 APIs,保障数据全部已经预先加载了呢?一般有两种方法:

react-router 的解决方案是配置路由 route-config,结合 matchRoutes,找到页面上相关组件所需的请求接口的方法并执行请求。这就要求开发者通过路由配置信息,显式地告知服务端请求内容。

我们首先配置路由:

在服务端代码中:

比如定义静态 loadData 方法,在服务端渲染时,我们可以遍历所有组件的 loadData,获取需要请求的接口。这样的方式借鉴了早期 React-apollo 的解决方案,我个人很喜欢这种设计。这里贴出我为 Facebook 团队著名的 react-graphQl-apollo 开源项目贡献的改动代码,其目的就是遍历组件,获取请求接口:

但是一个重要细节是:以 Next.js 为例,getInitialData 的方法必须要注册在根组件 App 当中。这样做的目的在于减少子孙组件的渲染。因为如果子孙组件也注入了 getInitialData 方法,那么如果不进行渲染,自然也就无法收集到该子孙组件 getInitialData 方法。

也就是说,基于 walkTree 的方案或者其他非配置化方案,我们都需要在服务端渲染两次。第一次的目的在于收集请求,第二次才是 renderToString 得到真正的渲染结果。

我们项目中的整个 isomorphic 过程可以简化为:

更多内容由于敏感性,不再展开。

令人期待的 React.suspense 可以解决 double rendering 的问题,但你知道原理是什么吗?后续我会写文章分析,欢迎关注~

注水和脱水,是同构应用最为核心和关键的细节点。

请求认证处理

上面讲到服务端预先请求数据,那么思考这样的场景:某个请求依赖 cookie 表明的用户信息,比如请求“我的学习计划列表”。这种情况下服务端请求是不同于客户端的,不会有浏览器添加 cookie 以及不含邮其他相关的 header 信息。这个请求在服务端发送时,一定不会拿到预期的结果。

为了解决这个问题,我们来看看 React-apollo 的解决方法:

这个做法也非常简单,原理是:服务端请求时需要保留客户端页面请求的信息,并在 API 请求时携带并透传这个信息。上述代码中,createHttpLink 方法调用时:

这个配置项就是关键,它使得服务端的请求完整地还原了客户端信息,因此验证类接口也不再会有问题。

样式问题处理

同构应用的样式处理容易被开发者所忽视,而一旦忽略,就会掉到坑里。比如,正常的服务端渲染只是返回了 HTML 字符串,样式需要浏览器加载完 CSS 后才会加上,这个样式添加的过程就会造成页面的闪动。

再比如,我们不能再使用 style-loader 了,因为这个 webpack loader 会在编译时将样式模块载入到 HTML header 中。但是在服务端渲染环境下,没有 window 对象,style-loader 进而会报错。一般我们换用 isomorphic-style-loader 来实现:

同时 isomorphic-style-loader 也会解决页面样式闪动的问题。它的原理也不难理解:在服务器端输出 html 字符串的同时,也将样式插入到 html 字符串当中,将结果一同传送到客户端。

isomorphic-style-loader 具体做了什么呢,他是如何实现的?

我们知道对于 webpack 来说,所有的资源都是模块,webpack loader 在编译过程中可以将导入的 CSS 文件转换成对象,拿到样式信息。因此 isomorphic-style-loader 可以获取页面中所有组件样式。为了实现的更加通用化,isomorphic-style-loader 利用 context API,在渲染页面组件时获取所有 React 组件的样式信息,最终插入到 HTML 字符串中。

在服务端渲染时,我们需要加入这样的逻辑:

最后我们用 [...css].join('') 就可以获取页面的所有样式字符串。

强调一下,isomorphic-style-loader 的源码目前已经更新,采用了最新的 React hooks API,我推荐给 React 开发者阅读,相信一定收获很多!

meta tags 渲染

App 组件嵌入到 document.querySelector('#root') 节点当中,一般是不包含 head 标签的。但是单页应用在切换路由时,可能也会需要动态修改 head 标签信息,比如 title 内容。也就是说:在单页面应用切换页面,不会经过服务端渲染,但是我们仍然需要更改 document 的 title 内容。

那么服务端如何渲染 meta tags head 标签就是一个常被忽略但是至关重要的话题,我们往往使用 React-helmet 库来解决问题。

Home 组件:

Users 组件:

React-helmet 这个库会在 Home 组件和 Users 组件渲染时,检测到 Helmet,并自动执行副作用逻辑。执行副作用的过程:React-helmet 依赖了 react-side-effect 库,该库作者就是大名鼎鼎的 Dan abramov,也推荐给大家学习。

404 处理

当服务端渲染时,我们还需要留心对 404 的情况进行处理,有 layout.js 文件如下:

当访问:/home 时,会得到一个空白页面,浏览器也没有得到 404 的状态码。为了处理这种情况,我们加入:

并创建 NotFound.js 文件:

注意,在访问一个不存在的地址时,我们要返回 404 状态码。一般 React router 类库已经帮我们进行了较好的封装,Static Router 会注入一个 context prop,并将 context.notFound 赋值为 true,在 server/index.js 加入:

即可。这一系列处理过程没有什么难点,但是这种处理意识,还是需要具备的。

安全问题

安全问题非常关键,尤其是涉及到服务端渲染,开发者要格外小心。这里提出一个点:我们前面提到了注水和脱水过程,其中的代码:

非常容易遭受 XSS 攻击,JSON.stringify 可能会造成 script 注入。因此,我们需要严格清洗 JSON 字符串中的 HTML 标签和其他危险的字符。我习惯使用 serialize-javascript 库进行处理,这也是同构应用中最容易被忽视的细节。

另一个规避这种 XSS 风险的做法是:将数据传递个页面中一个隐藏的 textarea 的 value 中,textarea 的 value 自然就不怕 XSS 风险了。

这里给大家留一个思考题,React dangerouslySetInnerHTML API 也有类似风险,React 是怎么处理这个安全隐患的呢?

性能优化

我们将数据请求移到了服务端,但是依然要格外重视性能优化。目前针对于此,业界普遍做法包括以下几点。

使用缓存:服务端优化一个最重要的手段就是缓存,不同于传统服务端缓存措施,我们甚至可以实现组件级缓存,业界 walmartlabs 在这方面的实践非常多,且收获了较大的性能提升。感兴趣的读者可以找到相关技术信息。

采用 HSF 代替 HTTP,HSF 是 High-Speed Service Framework 的缩写,译为分布式的远程服务调用框架,对外提供服务上,HSF 性能远超过 HTTP。

对于服务端压力过大的场景,动态切换为客户端渲染。

NodeJS 升级。

React 升级。

如图所示,React 16 在服务端渲染上的性能对比提升:

Beyond isomorphic

短短篇幅其实仍然无法说清楚同构应用的方方面面,如何优雅地设计一个 isomorphic 应用,将是开发者设计功力的体现。

在普通的 renderToString 调用之上,更“强大”、更“牛”的设计,比如我们需要关心以下问题:

如何在服务端获取数据,包含获取深层组件跨层级的数据和携带鉴权信息的数据

服务端渲染和客户端渲染的一致性

SPA 服务端渲染的一致性问题

同构项目中,JS 和 CSS 内联和外联设计

真正意义的流式渲染(区分假 renderToNodeStream 和 FaceBook 的 BigPipe)

Node 端请求的 timeout 时间设计,结合客户端动态“接力”渲染,服务端先返回带有 script 标签的(带有空数据指明信息)的 html 内容

最后一点我稍微提一下,我设计的理想同构应用的轮子启动时,获取一个 timeout 参数。服务端渲染真正在于服务端请求数据。在实际应用中比如,当前应用需要在服务端请求 6 组 RPC,在请求过程中超时(这个 timeout 由业务方设置),只拉取了 4 个接口,注水 4 组数据源。为了缩短 TTFB 的时间,服务端优先返回,剩下的未请求到的 2 个接口数据通过 script 标签注入页面,并进行返回,这样客户端超时前即可渲染页面。

开源的 react-server.io 也实现了类似功能,同时它通过指令化的组件,来做到服务端渲染时,数据的顺序可控性:

注意 RootElement 的 when props,以及 RootContainer 的 listen props,顾名思义,这些都实现渐进式渲染和服务端控制。

与此相关的其他概念以及上述技术细节的实现,由于篇幅原因,这里不再展开,未来我讲针对更高阶的同构应用设计产出更多文章。

最后,服务端渲染和目前革命性趋势 serverless 的结合也很值得期待,前一段在和狼叔聊天时得知阿里在积极尝试同构应用在 serverless 环境下的架构设计,我个人未来长期看好,也会在这个主题上分享更多内容。总结

本讲没有“手把手”教你实现服务端渲染的同构应用,因为这些知识并不困难,社区上资料也很多。我们从更高的角度出发,剖析同构应用中那些关键的细节点和疑难问题的解决方案,这些经验来源于真刀真枪的线上案例,如果读者没有开发过同构应用,也能从中全方位地了解关键信息,一旦掌握了这些细节,同构应用的实现就会更稳、更可靠。

同构应用其实远比理论复杂,绝对不是几个 APIs 和几台服务器就能完成的,希望大家多思考、多动手,一定会更有体会。

另外,同构应用各种细节也不止于此,坑也不止于此,还有更多 NodeJS 层面的设计也没有设计,欢迎大家和我讨论,保持联系,我也会贡献更多内容和资源。

关于本文作者:@LucasHC原文:https://zhuanlan.zhihu.com/p/79203739

为你推荐

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190823A0DKYV00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券