SSR 页面路由

背景

在做一个不依赖框架的架构，页面由模块构成，开发者只需要开发模块，页面和数据的组装由框架实现。 渲染页面时，会先去请求必要数据，然后将所有页面的所有模块都渲染出来。前端页面进行切换时，使用 CSS 的 display 属性进行隐藏和展示来实现页面的切换。 直接请求所有页面的模块实际上是不合理的。首先，在 node 端渲染时，需要将所有模块的渲染出来，如果一次渲染多个页面的模块，会导致渲染的时间加上，首屏的时间也就越长。此外，如果在页面上已经做过一些修改，采用 CSS 方案切换到一个页面再切换回来后仍然是之前修改过的 UI，而不是页面的初始状态。基于这些原因，需要将每个页面的渲染拆开，按需加载页面。

方案调研

思路

请求首页一定是 SSR，那么后续如何去管理和切换页面可以分为前端控制和 SSR 服务端控制两种思路。

前端控制

基于前端的思路是首屏请求时能返回所有页面的数据，这样 SSR 完成渲染后，能够将控制权交还前端。此时，前端管理整个 WebApp，以 SPA 的方式来实现路由的切换和跳转。 CSR 能做到切换页面时无刷新更新，前端监听路由的变化来实现模块的替换。但是需要在初次请求时就将所有数据返回，首屏的时间也会变长。

SSR 服务端控制

基于服务端控制的思路是将所有页面进行拆分，请求后续页面时还是会向服务端发送请求，服务端做好渲染后，将渲染好的字符串返回前端，前端再进行展示。 虽然 SSR 来实现页面的切换能够做到按需加载，但是无法做到无刷新更新。另外，服务端渲染和再次请求必要数据都是需要耗费一定的时间，在前端上会展示为跳转页面会有一定的白屏时间。

返回整个 APP

整个的流程与目前的流程类似，在请求某页时，返回的是整个路由+页面的形式。由于返回的是整个 APP，所以前端能够完全控制页面的切换，比 CSS 控制相比起来更加合适也更加灵活。

优劣势

• 前端控制灵活

• 整个 APP 只需请求一次数据，适合目前的架构

• 拉取了所有页面的资源，没有做到按需加载

SSR 返回单页面

与返回整个 APP 不同，每次请求一个页面时，只返回当前页面下的内容。后端根据路由指向获取到制定页面的模块，只对当前页面的模块做渲染。 在渲染页面之前，需要请求一些必要的数据，但是使用这种模式，每次请求页面都需要重新发起请求。相当于整个 APP 拆分为一个多页应用。

优劣势

• 能够实现按需加载

• 需要额外发起相同请求

genesis

Genesis 是基于 Vue 的 SSR 项目，它在页面的 SSR 之上，封装了一层聚合服务的概念，用来管理路由。一个聚合服务就是一个 App，SSR 与前端结合使用。提供出来一个单独的库来提供服务端与前端的路由同步。

优劣势

• 需要单独的聚合服务来维护路由与页面关系

• 能够做到按需加载

• 整个 APP 只需请求一次数据

预渲染

用户请求前的服务器渲染，构建阶段生成匹配预渲染路径的 html 文件。每个需要预渲染的路由都有一个对应的 html。 由于这个过程是在构建中进行，在构建时针对特定路由简单的生成静态 html 文件，所以无需服务器实时动态编译。

优劣势

• 不适用于动态路由

• 若网站有过多的路由，预编译会非常慢

• 更好的 SEO，更快的内容到达时间

改造方案

分析

由于本身的渲染流程只基于 preact 的渲染函数，每个页面的组装并不依赖框架来进行组合。所以，路由的方案较难走通（每个模块渲染出来就是一个 dom，页面为模块的列表）。 在渲染模块的过程中，需要一些基础数据，这些数据包含数据源/旧悟空平台的配置/url 参数等信息，这些信息在一次渲染过程中实际上应该是不变的。进行同一个 APP 的不同页面渲染时，这些数据是可以复用的。因此，在首次页面返回时，可将这些数据进行返回，存储于前端。 当前端进行页面切换时，在前端通过下一个页面模块的源码加之前返回的必要数据进行渲染。渲染完成后，页面切换完成。