SSR 页面路由
背景
在做一个不依赖框架的架构，页面由模块构成，开发者只需要开发模块，页面和数据的组装由框架实现。 渲染页面时，会先去请求必要数据，然后将所有页面的所有模块都渲染出来。前端页面进行切换时，使用 CSS 的 display 属性进行隐藏和展示来实现页面的切换。 直接请求所有页面的模块实际上是不合理的。首先，在 node 端渲染时，需要将所有模块的渲染出来，如果一次渲染多个页面的模块，会导致渲染的时间加上，首屏的时间也就越长。此外，如果在页面上已经做过一些修改，采用 CSS 方案切换到一个页面再切换回来后仍然是之前修改过的 UI，而不是页面的初始状态。基于这些原因，需要将每个页面的渲染拆开，按需加载页面。
方案调研
思路
请求首页一定是 SSR，那么后续如何去管理和切换页面可以分为前端控制和 SSR 服务端控制两种思路。
前端控制
基于前端的思路是首屏请求时能返回所有页面的数据，这样 SSR 完成渲染后，能够将控制权交还前端。此时，前端管理整个 WebApp，以 SPA 的方式来实现路由的切换和跳转。 CSR 能做到切换页面时无刷新更新，前端监听路由的变化来实现模块的替换。但是需要在初次请求时就将所有数据返回，首屏的时间也会变长。
SSR 服务端控制
基于服务端控制的思路是将所有页面进行拆分，请求后续页面时还是会向服务端发送请求，服务端做好渲染后，将渲染好的字符串返回前端，前端再进行展示。 虽然 SSR 来实现页面的切换能够做到按需加载，但是无法做到无刷新更新。另外，服务端渲染和再次请求必要数据都是需要耗费一定的时间，在前端上会展示为跳转页面会有一定的白屏时间。
返回整个 APP
整个的流程与目前的流程类似，在请求某页时，返回的是整个路由+页面的形式。由于返回的是整个 APP，所以前端能够完全控制页面的切换，比 CSS 控制相比起来更加合适也更加灵活。
优劣势
前端控制灵活
整个 APP 只需请求一次数据，适合目前的架构
拉取了所有页面的资源，没有做到按需加载
SSR 返回单页面
与返回整个 APP 不同，每次请求一个页面时，只返回当前页面下的内容。后端根据路由指向获取到制定页面的模块，只对当前页面的模块做渲染。 在渲染页面之前，需要请求一些必要的数据，但是使用这种模式，每次请求页面都需要重新发起请求。相当于整个 APP 拆分为一个多页应用。
优劣势
能够实现按需加载
需要额外发起相同请求
genesis
优劣势
需要单独的聚合服务来维护路由与页面关系
能够做到按需加载
整个 APP 只需请求一次数据
预渲染
用户请求前的服务器渲染，构建阶段生成匹配预渲染路径的 html 文件。每个需要预渲染的路由都有一个对应的 html。 由于这个过程是在构建中进行，在构建时针对特定路由简单的生成静态 html 文件，所以无需服务器实时动态编译。
优劣势
不适用于动态路由
若网站有过多的路由，预编译会非常慢
更好的 SEO，更快的内容到达时间
改造方案
分析
由于本身的渲染流程只基于 preact 的渲染函数，每个页面的组装并不依赖框架来进行组合。所以，路由的方案较难走通（每个模块渲染出来就是一个 dom，页面为模块的列表）。 在渲染模块的过程中，需要一些基础数据，这些数据包含数据源/旧悟空平台的配置/url 参数等信息，这些信息在一次渲染过程中实际上应该是不变的。进行同一个 APP 的不同页面渲染时，这些数据是可以复用的。因此，在首次页面返回时，可将这些数据进行返回，存储于前端。 当前端进行页面切换时，在前端通过下一个页面模块的源码加之前返回的必要数据进行渲染。渲染完成后，页面切换完成。
最后更新于
这有帮助吗？