简聊前端中的 React.js

原文贴在公司网站上, 半个月前发布的, 原文没有强制换行. 在这边备份一遍加上换行.
https://www.teambition.com/en...

更多关于 React 的消息可以看 React 中文社区导航页面:
http://nav.react-china.org
查找 React 中文文档请往 https://doc.react-china.org/

---

太早的事情需要看微博和 Git commits 记录才能知道了.
去年一月份我接触到过 React, 当时我关注的技术是 Ractive.
也是我快要到 Teambition 的时间, 简聊(https://jianliao.com/)也刚好是那时候开始的.
后来我关注的技术是 Vue, 直到 5 月份开始转投 React, 因为语法障碍克服了.
大致也就是现在简聊用 CoffeeScript 写 React 的原因.
用了 10 月中旬侧边栏引入了 React, 今年 1 月中旬去掉了 Backbone 依赖.

用这篇文章梳理一下, 目前简聊在 React 方面的进展, 以及有待研究的方面.

简述, 进展, 方向

• 进展

React 在 Teambition 的使用范围限制在简聊这个单页面应用之内.
目前应用本身对 jQuery 依赖已经移除, DOM 操作也在之前全从 jQuery 迁移.
简聊代码中创建了 20 个左右公用组件, 大约 120 个其他的组件.

部分较通用的代码, 计划拆分为模块在 GitHub 托管, 以及进行后续维护,
实际感受单页面的组件绑定业务逻辑会比较多, 因此通用性也有折扣.

https://github.com/teambition...
https://github.com/teambition...
https://github.com/teambition... (试验性)
https://github.com/teambition...

此前简聊代码使用的是 Backbone, 因此上面的对比基于 Backbone.
组件化, 界面的可维护性, 路由, DOM 操作的效率, 都提升得很好.
比如消息流之前加载很慢, 但是改成 React 之间自动合并了批量操作, 性能提升很明显.
View 部分是我们投入时间较多的部分, 功能也抓得比较紧.
React 对组件化的帮助非常大, 拆分模块非常方便, 因此简聊模块才特别多.
我也努力在让组件的通用性变得更强, 效果相对此前的 Backbone 也算满意.
另外 react-router 也很好得满足了我们的需要

我个人认为 jQuery 对 MVC 存在误导, 建议尽量避免手动的 DOM 操作.
Angular 跟 React 都是在 DOM 操作层面建立起更高级的抽象,
这个区别类似汇编语言的 goto label 结构跟高级语言的 for while 甚至 map reduce 方法的区别,
也就是对低级操作的细节进行封装.

• 需要跟进

React 的数据层方案不够成熟, 实际上目前我们的数据层也极为简单.
仅仅是 JSON 保存的数据, 参考官方 Flux 写的简单的 store.
面临的问题是性能优化不够, 稳健性也没有好的方案保证.
初步想法是引入 immutable-js, 目前只是局部模块使用, 还需要改进.
而且 Flux 的问题需要更多的经验深入考虑一下才行, 比较重要.
相对 Backone 来说, 方案更灵活, 但业务逻辑相对不够清晰, 各有利弊.

服务端渲染对前端来说, 主要页面初次加载复杂的 API 请求逻辑不够清晰.
其次是加载速度.. 不过加载速度是服务端渲染一做马上就能改观的事情.
除了初次加载问题, 切换路由时的数据加载, 也是前后端共用代码的难点.
React 提供了机会可以尝试 Isomorphic JavaScript 应用, 深入到数据路由界面全部代码共用.
目前还在收集资料阶段, 没有深入研究, 理想的目标是能帮助到公司其他的页面构建.

React 当中跨组件共享状态有难点, 而且排斥使用全局事件干扰数据流.
我相信这种限制是代码稳定可靠的一个手段, 但也会增加开发的难度.
有时我在设想能否借鉴 Om 之类方案, 用全局数据更好地管理状态?
因为在逻辑当中存在的多样的状态交换, 实在是需要想办法支持的.
这个方面没有很清晰的进展, 需要投入时间去摸索.

---

类库使用

目前开发环境代码优化后体积超过 1M, 采用 Webpack 进行了分包:

480K  js/main.59ad3c68fa5199b1268f.js
812K  js/vendor.7127c2f31156396dd4e9.js
172K  css/main.59ad3c68fa5199b1268f.css

具体到类库方面首先是框架功能上必需的一些:

• react(132k)
• flux
• moment(36k)
• emojitfy.js
• xss
• favico.js
• react-router
• sockjs-client
• spiderjs

大模块:

• jquery(计划弃用) 84k
• webuploader 71k(html5 52k)
• https://github.com/mailru/Fil... 43k(html5 34k)
• https://code.teambition.com/p...
• immutablejs https://github.com/facebook/i... 56k
• lodash 50k

小模块:

全局事件 https://github.com/Wolfy87/Ev...
selection 处理 https://github.com/timdown/ra...
Ajax 请求 https://github.com/ded/Reqwest
className 拼接 https://github.com/JedWatson/...
浏览器检测 https://github.com/ded/bowser
文件大小格式化 https://github.com/avoidwork/...
pen https://github.com/teambition...
pdfobject https://github.com/teambition...
thenjs https://github.com/teambition... 4.4k

CSS 模块

CSS 部分一个是图标字体的使用, 目前在公司统一的 UI 库当中.
也有 Bootstrap 的依赖, 而我一直在尝试弱化 Bootstrap 的部分.
目前只是部分引入, 希望以后有机会去除绝大部分 Bootstrap CSS.
Flexbox 是近期引入的, 为了提升代码质量开发效率, 放松兼容性, 有利有弊.

• tb-ui
• Bootstrap
• flex.less(Flexbox LESS mixin)

---

前端技术

React 部分

简聊整体建立在 React 跟 Webpack 上, 开发过程中一些资料放到了 SF.
这些我在社区交流比较多, 如果我们有更多时间整理技术, 会多做些交流.
因为我采用 CoffeeScript 书写 JSX, 跟社区很多可能理解有差别.

• React http://segmentfault.com/t/rea...
• Webpack http://segmentfault.com/t/web...

React-Hot-Replace 支持的热替换相比整页刷新方便了很多, 但也存在不足.
项目代码太多, 代码保存 2s 左右页面才能完成更新,
调试样式实时性不够, 甚至上线编译整个项目的时间也超过 40s.
js 报错的情况下, 依然需要手动刷新页面. 某些文件更改会导致页面整个刷新.
编译代码经过文件合并, 不如独立文件调试来得方便.

CSS

样式代码采用 LESS 为主, 我希望部分代码还是以 CSS 存在, 比如组件可以方面其他项目复用.
具体样式都参考 SMACSS 来进行规划, 效果比较好:

• SMACSS https://smacss.com/

另外随着 Flexbox 使用, 界面的结构化和代码的组件化会更轻松一些.
不过这个不是短期能搞定的, 而且具体兼容性还要花时间对付一下.

CSS 继承的问题是老大难, 非常难办, 继承完全不够在编写应用当中使用.
CSS 选择器极容易穿透组件作用到内层嵌套的组件当中.
单页面应用当中大量嵌套组件是非常常见的, 所以这明确是 CSS 的问题.
原本 CSS 本身不应该作为重点来应对, 但技术太不照顾单页面的场景了.
Web Components 普及之前似乎没有非常好的办法.

MV*

前端 MV* 模型的问题上, 基本上是 Flux, 而且还需要深入探索.
由于从 Backbone 转过来, 实际上代码用了大量的 listenTo 类似的实现.
嵌套太深, 于是内部的组件直接监听 store, 也显示出来 flux 在这方面不够强大.
我们没有采用第三方的管理 Store 或者 State 的类库, 而是官方基于 Demo 的手法改的:

• Flux https://github.com/facebook/f...

Flux 同时要考虑的还有上边说的 Isomorphic JavaScript 的问题.
我很认同 JavaScript 未来的方向, 借用一下 AirBnB 以前的一个图:

http://www.slideshare.net/spi...

补充下这张图, 因为我们是全栈 JavaScript, 所以具体场景会有些区别.
这同时要求有更清晰的对于前后端数据同步等等的认识.. 有待探索.

招聘

Teambition 的应用目前都在单页面上走得挺远, 需要研究的技术问题也增多.
期待更多同学加入推进这些方面问题的解决, 具体看仓库上.

另外我们建立了一个 repo 叫做 webapp-solutions 计划在上边梳理一些我们遇到的问题以及解决方案,
不会是以 React 为主, 但是计划在其中放一些 React 相关的解决方案, 希望大家参与.