关于从 Backbone 转向 React 的思考(部分过期)

这篇文章是我在迁移以前写的, 如今简聊(http://talk.ai)已经彻底切换到 React.
公司技术内容更新会贴在: http://weibo.com/teabot

---

原理

我以为 React 是我目前接触到的开发 Web 应用最好的一个方案.
我刚用熟 Backbone 时候在想模板引擎的做用, 怎样把数据转化成为界面,
在数据给定的状况下, 界面是彻底遵守数据改变的..
这个有点像数学里, 自变量因变量, 中间就被一个函数关联了,
更重要的, 其实数据咱们应该只存储一份, 因变量根据函数计算出来就行了

回到应用上来, 数据定义好后, 界面就彻底是根据数据渲染了
在 Backbone 中, 咱们须要频繁操做 DOM 来保证界面到达最新状态,
甚至有时候, 由于 DOM 上保存的状态和数据不一样步, 致使 Model 计算出错
这一切, 让我不断以为写应用时就不该该存在 DOM 操做

出于这些想法, 我开始学习了 Ractive, 而后是 Vue, 如今是 React.
React 的基本思路就是, 数据更新以后, 渲染完整的界面的状态,
而 DOM 则根据新的状态, 从原来的基础上, 作最小的操做, 来保证性能和状态

关于底层的细节, 代码我没看懂代码, 搜索到的资料上对于这部分有描述:

React’s diff algorithm
http://calendar.perfplanet.com/2013/diff/

摘录一些有意思的地方:

• 为了简化 DOM 算法复杂度, DOM 的 Diff 限制在层级同样的节点
• 列表渲染的节点, 须要提供 key 属性来区分出惟一性
• 对比到 Component 时, 整个 Component 不一样直接替换, 不按 DOM 比较
• React 的事件代理是本身实现的(和 jQuery 有区别, 我写应用遇到过)
• setState 方法能够将 DOM 标记须要从新渲染. 细化这个操做能够提高性能
• 能够定制 Component 的 shouldComponentUpdate 方法自行判断是否渲染, 提高性能

用户

主要是 Facebook 在生产环境使用了 React, 所以给人感受是挺靠谱的

How is Facebook's React JavaScript library?
http://www.quora.com/React-JS-Library/How-is-Facebooks-React-JavaScrip...

Using React to speed up the Khan Academy question editor
http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-academy.h...

Who is using Facebook React?
http://www.quora.com/React-JS-Library/Who-is-using-Facebook-React

搭配 CoffeeScript

我用 React 写了两个小应用, 感受 React 思路很是清晰,
对我来讲比较重要有一点是语法支持, 原生的 JSX 语法其实很是不方便编辑.
可是在 CoffeeScript 里, 语法就是很是简单的缩进, 比 HTML 清晰多了.

另外一个有意思的 Component 的概念, 相似 Backbone 的 View, 但轻量多了
并且, 由于 React 使用数据表达的 DOM, 写起来很是简化,
以及其组合的方式, 结果是 Component 的划分也很是明确和细化,
能够看个人应用里为了组合 Component 怎样划分的:

https://github.com/jiyinyiyong/react-todolist/tree/master/coffee/view

还有一个是, 由于界面是根据 Model 自动渲染的, 而操做 Model 其实很简单,
因而咱们就有大量的精力能够腾出来对付 Model 以及 ViewModel 相似的概念,
得益于此, 我用 React 轻松完成了 infinite scrolling 的效果, 彻底不用写 DOM 操做:

https://github.com/jiyinyiyong/osx-fonts-view/blob/master/coffee/main....

中型(大型?)项目关心的

个人我的项目不用 Backbone, 由于太臃肿了, 可是对公司的中型项目来讲还算合适,
因为我对于 React 的认同, 特别是 Facebook 用在生产环境, 因此完成关心大应用的场景

• 性能

听说很高, 由于消耗的不是 DOM 操做的性能, 而是 JS 性能, JS 自己其实挺快的
我没找到个靠谱的测试, 能够补上..

• 复杂的 View

我实践过的例子比较简单, 大的项目 View 的组合很复杂, 以及复杂的交互,
首先, React 的架构很方便 View 的扩展, 相比 Backbone 更灵活,
React 的结构更像是后台应用, 一个数据库, 前面是灵活渲染各类的 View.
对此我仍是比较乐观的.

和 Backbone 对比

Backbone to React
http://joelburget.com/backbone-to-react/

这哥们写了一篇文章叫这个名字.. 不过看内容的好像不明确啊..
我说一下我如今的考虑的这些事情:

• 双向绑定

React 其实不是双向绑定, 仅仅是单向的从数据到视图的渲染
问题是 Backbone 没有...
我最近遇到的 DOM 和数据绑定的事情, 以为大量的手动绑定太痛苦了

• 状态切换

状态问题比较大, 好比 Backbone 渲染 View, 先用模版, 后用 jQuery
结果是对同个元素的渲染其实有两套方案在发挥做用..
这样的重复确定会让人累, 其次, jQuery 命令式的操做方式显然是不友好的..

• 第三方的模块集成

用了 React 后, 对 DOM 的容忍就没那么好了, 至少比 Backbone 要差好多
在 Backbone 里, 强行把 jQuery 写的组件插进来尚且能作到,
在 React 里不用 jQuery, 因此已有的 jQuery 组件能不能直接用要从新思考了

• 对后端开发人员更友好

Backbone 渲染模版部分和服务端渲染很是类似, 可是到了复杂的消息就不对头了
为了 Backbone 的手法能 work, 要想尽办法转化为 Event 的方式
而 React 从理解上就是每次数据更新渲染整个页面, 没有推荐第二种方式...
就像是原来的, 每一个操做刷新页面的思路, 很是清晰,,,
考虑到先后端都是 JS, 这将给后端开发的人带来方便

• HTML 中空白的问题

最近用的模板引擎没有处理好 HTML 当中奇怪的空白, 致使出现意外的间隔
由于 React 是经过 Virtual DOM 转化的, 这样的空白就是不存在的
我花很多时间想把 Cirru 编译到 JS 模版来解决这个问题, 而 React 原生没就问题

• 模版语法

HTML 模版中咱们避免不了逻辑, 结果仍是会插入一些简单的逻辑进去
更麻烦的是, 有时候不想插逻辑的结果就是用 jQuery 去实现这部分逻辑
即使抛开这些, HTML 写多了, 上边这个状态那个状态, 就变得难看懂了

React 的 DOM 是从 JS 的数据结构里生成的, 所以没有维护和编译模版的麻烦,
不过也有人会说 JS 里写 DOM 会很难看, 由于... 反正就是很难看
的确, 当页面变大以后, 究竟会有多复杂我目前不清楚, 须要深刻看

• 数据结果更加随意

Backbone 里有 Collection 做为约束, 固然也提供了一些方便,
可是真实场景的应用将会比较复杂, Collection 共用数据就麻烦很多
最近碰到的例子, 多个 Collection 存在对应同个 User 的多份数据,
如每次都刷新, 从 id 生成界面, 不会有问题, 可是 Backbone 里不方便这么作

• 数据状态之间的切换

Backbone 麻烦的地方, 在于咱们用 jQuery 的时候, 手动维护状态切换
问题是, 可能有多种状态的时候, 就须要有多个状态之间切换的代码
这样的状态维护, 不是一份代码, 而不是状态和状态相乘的结果的代码,
虽然一般界面就是两个状态, 但某种程度上也是重复了一次操做.

期待

我想说 React 真的解决了好多 Backbone 里的问题...
若是要切换, 就要开始考虑 React 引入的新问题是哪些, 可否容忍或者减轻?
以及在大项目当中使用 React 的经验我也以为不足, 细节上并不能有定论
因此想找机会用 React 尝试一下稍微大一点的项目, 验证可用性

---

返回博客首页: http://blog.tiye.me/