React-SSR渲染调研

前期思考:

  • 1、nodejs环境如何加载前端组件
    • 选用koa、express、egg
  • 2、组件的数据如何获取
  • 3、HRM怎么做(热替换?热重载?CSS HMR)
    • 是否使用webpack-dev-server
    • CSS 不使用style-loader(modul.hot,accept),使用react-hot=loader来实现一个css-hot-loader
  • 4、css如何处理
  • 5、如何拼接完整的HTML结构返回
    • renderToNodeStream
    • ReactDOM.hydrate
  • 6、如何进行路由分割
    • 服务端路由和客户端路由公用一套
  • 7、如何降级为客户端渲染
    • 当服务端渲染出现问题是,降级为客户端渲染
    • 同时支持两种SSR以及CSR两种开发模式,无缝切换
  • 8、是否可以做到同构开发
  • 9、生成环境如何发布应用
    • 如何做到每次不更新服务,react这些静态资源更新后

同构开发需要考量的点

  • 代码或者框架层需要兼容server/client的runtime
    比较直接的一个就是fetch数据操作,如果服务端数据源有RPC协议或者请求的服务存在环境/网络隔离,需要封装成通用的http接口

  • 更复杂的部署和打包构建
    部署和大奥构建过程加倍,简单地理解就是单独的server和单独的client的工作综合

  • 增加服务端负责
    这个是SSR的通病,但使用同构开发方式后完全可以变成一个可有花的点,在使用同构方式时,可以正对服务端资源负载做监控,如果遇到服务端负载过大或者高峰时段,可以将渲染方式无缝切换成csr,待服务端负载正常或者流量回落时,在切换为SSR。

同构开发的优点

  • 服务端和客户端公用代码
  • 更快的页面内容达到时间
  • 更友好的SEO
  • 更优雅的降级方式,更健壮的应用

对比:beidou、next.js、easy team,对比方案

easy-team方案对比

  • 与服务端框架不耦合,easy-team的实现方式与egg框架耦合的太过紧密
  • 本地开发读取服务端bundle的方式更加优雅
  • 通过config.default.js同时两种渲染模式无缝切换而easy-team需要在构建时指定渲染类型

与next.js方案对比

  • 与服务端框架不耦合,next实现与http模块耦合紧密
  • 本地开发读取服务端的bundle的方式更加优雅
  • 体积小,同等复杂度项目大小为next.js生成文件的0.3b倍
  • 实现非黑盒,关键配置皆可以通过config.default.js来配置

理想模型:koa+react+ReactDOMServer+midway+webpack

bigpipe的优点,分块传输优点非常明显,且浏览器友好,fb和微博,qunar都是受益者,node天然支持,res.writer很友好

你可能感兴趣的:(React-SSR渲染调研)