安利一个React同构渲染脚手架 —— razzle

时间 2019-11-17

标签安利一个 react 同构渲染脚手架 razzle 栏目 React 繁體版

原文原文链接

本文发表于我的GitHub转载请注明出处css

什么是同构：

客户端渲染：页面在 JavaScript，CSS 等资源文件加载完毕后开始渲染，路由为客户端路由，也就是咱们常常谈到的 SPA（Single Page Application）。
服务端渲染：页面由服务端直接返回给浏览器，路由为服务端路由，URL 的变动会刷新页面，原理与 ASP，PHP 等传统后端框架相似。
同构：英文表述为 Isomorphic 或 Universal，即编写的 JavaScript 代码可同时运行于浏览器及 Node.js 两套环境中，用服务端渲染来提高首屏的加载速度，首屏以后的路由由客户端控制，即在用户到达首屏后，整个应用还是一个 SPA。

简而言之，同构是服务端直出和客户端渲染的结合html

同构的优势：

SEO更友好。
整个页面级别的应用会使得浏览器在解析dom完成以后立刻有东西能够渲染,减小渲染时间（首屏优化）。
服务端和客户端维护一份代码就好了。
开源福利：React16的发布经过重写了用于服务端渲染的renderToString函数，将渲染速度提高至v15的3倍。
等等

固然，同构也没有这么好，具体的的选择仍是看业务的，权衡开发(迁移)成本，性能影响等等诸多因素。react

那么问题来了:)

若是，我尝试下 React服务端渲染，但又不想本身一开始就纠结于较繁琐的配置呢？git

不少人的开发都会选用一个现有的脚手架开始，那么如何选用一个脚手架呢？github

关于一个框架的脚手架，在网上常常看到开发者这样说：

I'm looking for a very simple starter pack... I don't need all the hoopla.

的确，对一个脚手架项目而言，它须要有全部你想要的，不须要有你不想要的。typescript

react官方的脚手架create-react-app的README中提到 现阶段不支持直接提供服务端渲染。redux

那么有哪些支持同构渲染的脚手架呢？

好比这些：后端

这些脚手架各有各的特色，有的依赖多，有的依赖少，有的性能好，有的针对某一个痛点解决...数组

下面隆重介绍今天的主角 ———— razzle:

razzle 是一个把全部于服务端渲染相关的繁琐配置抽象成了单独的一个依赖，浏览器

给你相似于create-react-app的开发体验，

可是把剩下的架构决策权，好比框架选用，路由系统的选择、数据获取方式全都交给了开发者本身，充分符合上面说的:

have everything you need and nothing you don't.

razzle 和上述提到的其余支持同构渲染的框架的 最大不一样 在于他能过抽象依赖，可以提供相似create-react-app的开发体验，这就意味了给了开发者很大的自由度去选择本身顺手的，本身看得上眼的react生态里的库，razzle提供丰富的examples，帮助开发者可以快速的结合一些流行的成熟的库，好比用typescript进行开发，经过结合react-redux作状态管理，好比经过结合react-router作路由系统，经过结合react-loadable作到组件级别的代码分割和懒加载等等不少。

razzle 的理念决定了它不仅支持React，

还支持Reason,Elm,Vue,Angular,和将来的新框架:)

项目的主要的优势有：

开发环境模块热替换，无需重启就能够看到效果
你最喜欢的ES6 支持
与create-react-app 相同的 css 设置
不少框架的支持
默认Jest
零配置服务端渲染

关于同构有一些误区，列几个熟悉的：

同构性能没有客户端渲染好？网络流量高峰的时候，转到客户端渲染并不会起很大做用。ssr在服务端的渲染实际上是很是快的，尽管这里提供不了精确的数据支持，可是看了不少博客上都提到过这种观点。
同构容易引发内存泄漏？其实并非，只要注意不要盲目的在定时的函数体中向全局的数组push东西等等，注意组建生命周期componentDidMount中放置服务端执行不了的代码，而且注意在用一些如window变量前先进行判断就好，并非很容易致使内存泄漏。

理解还不是很成熟，但愿能与你们交流讨论。

笔者是razzle的项目使用者，受益者，但愿能让更多的人看到这个项目，将来一块儿让他更好。