简聊前端中的 React.js

原文贴在公司网站上,半个月前发布的,原文没有强制换行. 在这边备份一遍加上换行.
https://www.teambition.com/en/developer/blog/article?p=developer-blog&s=&_id=554c5296a37ffe95660eb0c0

更多关于 React 的消息可以看 React 中文社区导航页面:
http://nav.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/react-lite-dropdown
https://github.com/teambition/react-lite-layered
https://github.com/teambition/react-lite-uploader (试验性)
https://github.com/teambition/react-lite-misc

此前简聊代码使用的是 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/FileAPI 43k(html5 34k)
https://code.teambition.com/project/highlightjs/tree/master
immutablejs https://github.com/facebook/immutable-js 56k
lodash 50k

小模块:

全局事件 https://github.com/Wolfy87/EventEmitter
selection 处理 https://github.com/timdown/rangy/
Ajax 请求 https://github.com/ded/Reqwest
className 拼接 https://github.com/JedWatson/classnames
浏览器检测 https://github.com/ded/bowser
文件大小格式化 https://github.com/avoidwork/filesize.js
pen https://github.com/teambition/pen
pdfobject https://github.com/teambition/PDFObject
thenjs https://github.com/teambition/then.js/ 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/reactjs/blogs?page=2
Webpack http://segmentfault.com/t/webpack/blogs

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/flux/tree/master/examples/flux-chat/js

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

http://www.slideshare.net/spikebrehm/a-28174727?from_action=save

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

招聘

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

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