杰拉斯的博客

什么是前后端同构（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 前后端同构（服务端渲染）实践篇》

如需转载请注明出处：杰拉斯的博客

相关文章

• React+Webpack 前后端同构（服务端渲染）实践篇
• [设计模式]JavaScript钩子机制的应用场景与实现
• [小积累]不同浏览器中阻止默认事件、冒泡的方法
• 借@阿里巴巴 耍了个帅——HTML5 JavaScript实现图片文字识别与提取
• [实用小代码]网页中的各种长宽、坐标