React同构实践之实现自己的同构模板
一开始想学学服务端渲染,脑海中第一个浮现出来的就是next.js这种成熟的方案。看了一两天,有趣,优雅,但是封装好了,原理不甚清楚,也感觉无法灵活嵌合到老项目上去。于是看各种资料,想整理出同构的线索,一步一步地实现自己的同构模板。
TODO List
- 数据:如何保持前后端应用状态一致
- 路由:路由在服务端和客户端中的匹配方案
- 代码:同构,哪些地方可以共享,哪些地方需要差异化
- 静态资源:服务端如何引入css/图片等
- ssr直出资源:服务端在渲染路由页面时如何匹配css/chunks资源
- 打包方案:服务端和浏览器端如何写各自的webpack配置文件
- SEO: head头处理方案
同构的基础
正常的网页运行,需要生成dom,在dom树loaded之后由js绑定相关的dom事件,监听页面的交互。服务端并不具备dom的执行环境,因而所有的服务端渲染其实都是返回了一个填充了初始数据的静态文本。
在react中,除了常用的render这个用于生成dom的方法,还提供了renderToString,renderToStaticMarkup方法用来生成字符串,由于VitualDOM的存在,结合这些方法就可以像以前的字符串模板那样生成普通的字符串,返回给客户端接管,再接着进行事件相关的绑定。
最新的React v16+使用hydrate和ssr配套,能让客户端把服务端的VitualDOM渲染出来后得以复用,客户端加载js后不会重刷一边,减小了开销,也避免浏览器重刷dom时带来的闪屏体验。
而react的组件,还是和往常写spa一样编写,前后端共享。不同的只是入口的渲染方法换了名字,且客户端会挂载dom而已。
// clinet.js ReactDom.hydrate(<App />, document.getElementById('app')) // server.js const html = ReactDom.renderToString(<App />)
同构后网站运行流程图
盗用一张图,来自阿里前端。乍一看,ssr与csr的区别就在于2 3 4 5,spa模式简单粗暴地返回一个空白的html页面,然后在11里才去加载数据进行页面填充,在此之前,页面都处于空白状态。而ssr则会根据路由信息,提前获取该路由页面的初始数据,返回页面时已经有了初步的内容,不至于空白,也便于搜索引擎收录。
路由匹配
浏览器端的路由匹配还是照着spa来做应该无需费心。略过了...
服务端的路由需要关注的,一个是后端服务的路由(如koa-router)匹配的问题,一个是匹配到react应用后react-router路由表的匹配问题。
服务端路由,可通过/react前缀来和api接口等其他区别开来,这种路由匹配方式甚至能让服务端渲染能同时支持老项目诸如ejs等的模板渲染方式,在系统升级改造方面可实现渐进式地升级。
// app.js文件(后端入口) import reactController from './controllers/react-controller' // API路由 app.use(apiController.routes()) // ejs页面路由 app.use(ejsController.routes()) // react页面路由 app.use(reactController.routes()) // react-controller.js文件 import Router from 'koa-router' const router = new Router({ prefix: '/react' }) router.all('/', async (ctx, next) => { const html = await render(ctx) ctx.body = html }) 在此我向大家推荐一个前端全栈开发交流圈:619586920 突破技术瓶颈,提升思维能力 export default router
react-router专供了给ssr使用的StaticRouter接口,称之为静态的路由。诚然,服务端不像客户端,对应于一次网络请求,路由就是当前的请求url,是唯一的,不变的。 在返回ssr直出的页面后,页面交互造成地址栏的变化,只要用的是react-router提供的方法,无论是hash方式,还是history方式,都属于浏览器端react-router的工作了,于是完美继承了spa的优势。只有在输入栏敲击Enter,才会发起新一轮的后台请求。
import { StaticRouter } from 'react-router-dom' const App = () => { return ( <Provider store={store}> <StaticRouter location={ctx.url} context={context}> <Layout /> </StaticRouter> </Provider> ) }
应用状态数据管理
以往的服务端渲染,需要在客户端网页下载后马上能看到的数据就放在服务器提前准备好,可延迟展示,通过ajax请求的数据的交互逻辑放在页面加载的js文件中去。
换成了react,其实套路也是一样一样的。但是区别在于:
传统的字符串模板,组件模板是彼此分离的,可各自单独引入数据,再拼装起来形成一份html。而在react的ssr里,页面只能通过defaultValue和defaultProps一次性render,无法rerender。
不能写死defaultValude,所以只能使用props的数据方案。在执行renderToString之前,提前准备好整个应用状态的所有数据。全局的数据管理方案可考虑redux和mobx等。
需要准备初始渲染数据,所以要精准获取当前地址将要渲染哪些组件。react-router-config和react-router同源配套,是个支持静态路由表配置的工具,提供了matchRoutes方法,可获得匹配的路由数组。
import { matchRoutes } from 'react-router-config' import loadable from '@loadable/component' const Root = loadable((props) => import('./pages/Root')) const Index = loadable(() => import("./pages/Index")) const Home = loadable(() => import("./pages/Home")) 在此我向大家推荐一个前端全栈开发交流圈:619586920 突破技术瓶颈,提升思维能力 const routes = [ { path: '/', component: Root, routes: [ { path: '/index', component: Index, }, { path: '/home', component: Home, syncData () => {} routes: [] } ] } ] router.all('/', async (url, next) => { const branch = matchRoutes(routes, url) })
组件的初始数据接口请求,最美的办法当然是定义在各自的class组件的静态方法中去,但是前提是组件不能被懒加载,不然获取不到组件class,当然也无法获取class static method了,很多使用@loadable/component(一个code split方案)库的开发者多次提issue,作者也明示无法支持。不支持懒加载是绝对不可能的了。所以委屈一下代码了,在需要的route对象中定义一个asyncData方法。
服务端
// routes.js { path: '/home', component: Home, asyncData (store, query) { const city = (query || '').split('=')[1] let promise = store.dispatch(fetchCityListAndTemperature(city || undefined)) let promise2 = store.dispatch(setRefetchFlag(false)) return Promise.all([promise, promise2]) return promise } }
2
// render.js import { matchRoutes } from 'react-router-config' import createStore from '../store/redux/index' const store = createStore() const branch = matchRoutes(routes, url) const promises = branch.map(({ route }) => { // 遍历所有匹配路由,预加载数据 return route.asyncData ? route.asyncData(store, query) : Promise.resolve(null) }) // 完成store的预加载数据初始化工作 await Promise.all(promises) // 获取最新的store const preloadedState = store.getState() const App = (props) => { return ( <Provider store={store}> <StaticRouter location={ctx.url} context={context}> <Layout /> </StaticRouter> </Provider> )在此我向大家推荐一个前端全栈开发交流圈:619586920 突破技术瓶颈,提升思维能力 } // 数据准备好后,render整个应用 const html = renderToString(<App />) // 把预加载的数据挂载在`window`下返回,客户端自己去取 return <html> <head></head> <body> <div id="app">${html}</div> <script> window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState)}; </script> </body> </html>
客户端
为保证两端的应用数据一致,客户端也要使用同一份数据初始化一次redux的store,再生成应用。如果两者的dom/数据不一致,导致浏览器接管的时候dom重新生成了一次,在开发模式下的时候,控制台会输出错误信息,开发体验完美。后续ajax的数据,在componentDidMount和事件中去执行,和服务端的逻辑天然剥离。
// 获取服务端提供的初始化数据 const preloadedState = window.__PRELOADED_STATE__ || undefined delete window.__PRELOADED_STATE__ // 客户端store初始化 const store = createStore(preloadedState) const App = () => { return ( <Provider store={store}> <BrowserRouter> <Layout /> </BrowserRouter> </Provider> ) } // loadableReady由@loadabel/component提供,在code split模式下使用 loadableReady().then(() => { ReactDom.hydrate(<App />, document.getElementById('app')) })
服务端调用的接口客户端也必须有。这就带来了如何避免重复请求的问题。我们知道componentDidMount方法只执行一次,如果服务器已经请求的数据带有一个标识,就可以根据这个标识决定是否在客户端需要发起一个新的请求了,需要注意的是判断完成后重置该标识。
import { connect } from 'react-redux' @connect( state => ({ refetchFlag: state.weather.refetchFlag, quality: state.weather.quality }), dispatch => ({ fetchCityListAndQuality: () => dispatch(fetchCityListAndQuality()), setRefetchFlag : () => dispatch(setRefetchFlag(true)) }) ) export default class Quality extends Component { componentDidMount () { const { location: { search }, refetchFlag, fetchCityListAndQuality, setRefetchFlag } = this.props const { location: city } = queryString.parse(search) refetchFlag ? fetchCityListAndQuality(city || undefined) : setRefetchFlag() } }
打包方案
客户端打包
我想说的是“照旧”。因为在浏览器端运行的还是spa。入门级的具体见github,至于如何配置得赏心悦目,用起来得心应手,根据项目要求各显神通吧。
服务端打包
这里既可以把整个服务端入口app.js作为打包入口,也可以把react路由的起点文件作为打包入口,配置输出为umd模块,再由app.js去require。以后者为例(好处在于升级改造项目时尽可能地降低对原系统的影响,排查问题也方便,断点调试什么的也方便):
// webpack.server.js const webpackConfig = { entry: { server: './src/server/index.js' }, output: { path: path.resolve(__dirname, 'build'), filename: '[name].js', libraryTarget: 'umd' } } // app.js const reactKoaRouter = require('./build/server').default
css、image资源正常来说服务端无需处理,如何绕开 偷懒,还没开始研究,占个坑 require的是node自带的模块时避免被webpack打包
const serverConfig = { ... target: 'node' }
require第三方模块时如何避免被打包
const serverConfig = { ... externals: [ require('webpack-node-externals')() ]
生产环境代码无需做混淆压缩
服务端直出时资源的搜集
服务端输出html时,需要定义好css资源、js资源,让客户端接管后下载使用。如果没啥追求,可以直接把客户端的输出文件全加上去,暴力稳妥,简单方便。但是上面提到的@loadable/component库,实现了路由组件懒加载/code split功能后,也提供了全套服务,配套套装的webpack工具,ssr工具,帮助我们做搜集资源的工作。
// webpack.base.js const webpackConfig = { plugins: [ ..., new LoadablePlugin() ] } // render.js import { ChunkExtractor } from '@loadable/server' const App = () => { return ( <Provider store={store}> <StaticRouter location={ctx.url} context={context}> <Layout /> </StaticRouter> </Provider> ) } const webStats = path.resolve( __dirname, '../public/loadable-stats.json', // 该文件由webpack插件自动生成 ) 在此我向大家推荐一个前端全栈开发交流圈:619586920 突破技术瓶颈,提升思维能力 const webExtractor = new ChunkExtractor({ entrypoints: ['client'], // 为入口文件名 statsFile: webStats }) const jsx = webExtractor.collectChunks(<App />) const html = renderToString(jsx) const scriptTags = webExtractor.getScriptTags() const linkTags = webExtractor.getLinkTags() const styleTags = webExtractor.getStyleTags() const preloadedState = store.getState() const helmet = Helmet.renderStatic() return <html> <head> ${helmet.title.toString()} ${helmet.meta.toString()} ${linkTags} ${styleTags} </head> <body> <div id="app">${html}</div> <script> window.STORE = 'love'; window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState)}; </script> ${scriptTags} </body> </html>
SEO信息
上面已经透露了。使用了一个react-helmet库。具体用法可查看官方仓库,信息可直接写在组件上,最后根据优先级提升到head头部。
结语
感谢您的观看,如有不足之处,欢迎批评指正。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
什么是消息队列?
前言 只有光头才能变强。 文本已收录至我的GitHub仓库,欢迎Star:https://github.com/ZhongFuCheng3y/3y 公司用到的很多技术,自己之前都没学过(尬),于是只能慢慢补了。这次给大家写写我学习消息队列的笔记,希望对大家有帮助。 一、什么是消息队列? 消息队列不知道大家看到这个词的时候,会不会觉得它是一个比较高端的技术,反正我是觉得它好像是挺牛逼的。 消息队列,一般我们会简称它为MQ(Message Queue),嗯,就是很直白的简写。 我们先不管消息(Message)这个词,来看看队列(Queue)。这一看,队列大家应该都熟悉吧。 队列是一种先进先出的数据结构。 在Java里边,已经实现了不少的队列了: 那为什么还需要消息队列(MQ)这种中间件呢???其实这个问题,跟之前我学Redis的时候很像。Redis是一个以key-value形式存储的内存数据库,明明我们可以使用类似HashMap这种实现类就可以达到类似的效果了,那还为什么要Redis?《Redis合集》 到这里,大家可以先猜猜为什么要用消息队列(MQ)这种中间件,下面会继续补充。 消息队列...
- 下一篇
偏向锁到底是怎么回事啊啊啊啊
微信公众号:IT一刻钟 。大型现实非严肃主义现场 一刻钟与你分享优质技术架构与见闻,做一个有剧情的程序员。 关注可第一时间了解更多精彩内容,定期有福利相送哟。 话说有这么一件事。 于是当天夜里,小哥哥便哼哧哼哧的画出了偏向锁的逻辑图。 其逻辑呢,各位看官待我慢慢道来。 看一张大图 (点击看大图) 流程讲解 当JVM启用了偏向锁模式(JDK6以上默认开启),新创建对象的Mark Word中的Thread Id为0,说明此时处于可偏向但未偏向任何线程,也叫做匿名偏向状态(anonymously biased)。 偏向锁逻辑 1.线程A第一次访问同步块时,先检测对象头Mark Word中的标志位是否为01,依此判断此时对象锁是否处于无所状态或者偏向锁状态(匿名偏向锁); 2.然后判断偏向锁标志位是否为1,如果不是,则进入轻量级锁逻辑(使用CAS竞争锁),如果是,则进入下一步流程; 3.判断是偏向锁时,检查对象头Mark Word中记录的Thread Id是否是当前线程ID,如果是,则表明当前线程已经获得对象锁,以后该线程进入同步块时,不需要CAS进行加锁,只会往当前线程的栈中添加一条Disp...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 2048小游戏-低调大师作品
- CentOS8编译安装MySQL8.0.19
- Hadoop3单机部署,实现最简伪集群
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Linux系统CentOS6、CentOS7手动修改IP地址