React+Webpack 前后端同构(服务端渲染)理论篇

蓝飞 蓝飞 | 时间:2016-09-08, Thu | 2,502 views
前端开发, 后台技术 

什么是前后端同构(isomorphic)?

其实在这个问题上,我想了很久都没有想出一个比较好的答案。前后端同构,简单地说就是前后端共用一份代码,但这样讲起来,未免有点食之无味,所以我们还是先讲讲 Web 服务端渲染的历史,了解一下前后端同构是在什么场景下衍生出来,它又能够解决什么样的问题。

前后端揉和时代

如果大家写过 ASP/PHP 的话,大概就会记得,曾经的 Web 程序员,并不分前端工程师和后端工程师,ASP/PHP 逻辑与 HTML 结构混搭, <?php ?><div> 一色,for<li> 齐飞,当项目大起来后,代码可读性极差,极难维护,而调试前端样式,还需要搭后端环境,跑起一个庞大服务,开发效率非常低下,于是衍生了下一个时代——

模板引擎时代

这个时候大家开始强调前后端分离,前后端工程师各司其职,前端程序员写模板文件,后端程序员写后端逻辑,最后通过模板引擎和模板语言结合起来,比如著名的『Smarty』模板引擎。

然而项目总还是会有大的时候→_→有时候界面不一定由服务端渲染,很多场景都会需要 AJAX 请求后端接口,再在页面上动态生成 DOM 结构,字符串拼接可读性差,于是又引入一套前端模板引擎,而如果某个样式需要修改,那么前后端涉及的模板代码都得同步修改……

前后端同构时代

幸而 Node 踩着七色云彩来娶我,哦不,是将 JavaScript 带到了服务端,前后端相同的语言给同构的出现创造了绝佳的条件。从此 Web 开发者们只需要维护一套代码,就可以在前后端渲染出同样的结果,并过上了没羞没臊的幸福生活╮(╯▽╰)╭。

为什么要前后端同构?

简单列几点:

  1. 相对于纯前端渲染来说,更利于 SEO
  2. 相对于纯前端渲染来说,首屏加载更快
  3. 提高了复用性,代码更容易维护

实现同构需要解决的问题

理想是丰满的,现实是骨感的,在实现前后端同构的路上,我们会不可避免的遇到几个问题:

运行环境差异

有些逻辑是只能运行于浏览器端的,比如 AJAX 请求,浏览器事件等等,应置于 componentDidMount 生命周期(含)以后,或者通过 window 关键字进行判断。

模块管理差异

我们通过 Webpack,可以实现样式、图片等各种资源的模块化管理,但 Node 的 require 可没有 Webpack 的魔法特性,我们可以通过 webpack-isomorphic 工具来解决。

前端渲染数据来源

服务端渲染时,React 组件的 state 只存在于服务器内存中,而生命周期方法只会执行到 componentDidMount 以前,那么前端如何将组件重新实例化,并将剩余的生命周期方法执行完呢?我们需要把服务端数据同步到前端,前端的 React 才能够在浏览器中进行组件的实例化,保证 Web 应用正常运行。

前后端路由同步

如果你的应用是单页应用(SPA),那么应该确保前后端路由一致,否则可能出现页面跳转可以正常访问,但刷新后却出现异常的情况。

欲知后事如何,请听下回分解:《React+Webpack 前后端同构(服务端渲染)实践篇

如需转载请注明出处:蓝飞技术部落格

更多

3 条评论 »

  1. 楼主,这是什么?能说下吗

    1. 刚刚插件出了点问题乱码了,先已修复,不好意思

  2. 林鉴伟 林鉴伟

    我次奥,居然没抢到沙发