论坛风格切换切换到宽版
  • 6318阅读
  • 0回复

Localytics 经验 AngularJS代替Backbone 代码减一半 [复制链接]

上一主题 下一主题
 

发帖
1077
只看楼主 倒序阅读 使用道具 楼主  发表于: 2013-04-19
Localytics是一家移动分析数据提供商,提供实时分析服务,帮助移动电话和平板电脑的应用开发商更好地理解用户。Localytics在使用AngularJS代替Backbone开发App后,不仅使工作变得轻松,而且代码数量缩减了一半。

Biggie Smalls曾说过:“代码越多,问题也就越多”。反言之,代码越少,则越利于功能模块的维护与性能的提升。这篇文章讲了移动分析数据提供商Localytics在使用Backbone开发应用时遇到的种种问题,而在采用AngularJS代替Backbone后,代码量却减少了一半。

与Backbone一起的日子

开始时,代码很乱,错综复杂,而在使用Backbone后,这一问题得到了解决,并一直稳定运行。我们的数据放置在模型里,并且把模型放置在由视图观察的集合里。但随着应用越来越复杂,要在更深层次嵌入视图,恶梦却开始了,最终我们感到了绝望。

在我们真正的应用当中,Backbone做了一个简单但我们却无法实现的承诺:
在一个用Backbone开发的App里,你必须编写胶合代码(glue code)到DOM里面查找一个拥有特定id的元素,然后手动更新HTML——当模型发生变化时,视图也会随之更新。


我们发现,这种说法是存在误导的。

在Backbone里,View.render是一个no-op(空操作),所以上面那段话最好这样描述:“当模型更改时,你需要把视图绑定到相应的模型事件上,然后编写个渲染方法留作调用,并且在完成后解除绑定。”而对我们来说,真是说起来容易,做起来难:

首先,为了保持视图易管理,我们依照thoughtbot例子编写了一些复合视图,这些复合视图由许多负责离散页面的小视图所组成。父视图得跟踪子视图并且对它们进行清理,而在嵌套视图中,每个渲染方法该如何做就变得模糊了。它是应该先渲染自己,然后在重新创建去渲染所有的子视图,还是重用所有子视图并且一起进行渲染?最后,我们编写了许多行代码并且管理复合视图库类,这里花费了太多的时间来修复那些无用的僵尸视图,但是它们没有被完全正确地清理出去。

其次,我们的应用程序过分依赖用户输入,并且我们也未找到一个好的方法来保持表单输入、模型和视图同步。首先,我们编写胶合代码到DOM里面查找一个拥有特定id的元素,然后根据元素的keypress来抓取数据。而这也就导致模型发生改变,监察视图重新渲染,随之而来的是输入失去焦点。所以,为了替代简单的整个模板渲染,我们编写了更多的胶合代码,并且改变了元素映射在模型上的值。如今,在我们的视图里拥有双倍的DOM处理代码,所以我们转向使用了一个小的双向数据绑定库Stickit

事情并没有我们想的那么简单,使用Stickit后反而变得更糟了。最后我们又使用了一个jQuery插件Chosen,然而它与Stickit不兼容并且无法把Backbone视图插入到DOM中。但我们仍然在坚持,写了大量代码来使三者结合起来。所以当对我们的App营销平台进行UI改造时,我们意识到不得不对现有代码进行重构,借此来尝试一些新的东西。
采用AngularJS

AngularJS声明式的双向数据绑定听起来不错,而当我们发现AngularUI带有一个和Chosen极为相似的日期选择器时,我们决定采用它。

起初,我们并没有发现与之前相似的模型、集合这类东西,我们甚至都不知道该如何模拟我们的数据、该如何组织我们的代码,更糟地是,AngularJS文档对我们的帮助也不大。最后我们决定不再依照原有那个千疮百孔的代码,事实证明这样做是正确的。

我们只用了2周时间就完成了项目,而代码量仅为之前的一半。

数据绑定很神奇,我们没有编写任何DOM操作代码,也没有把时间花在追踪内存泄漏或不可预测的事件绑定行为上。

更让我们感到惊喜地是,AngularJS的模块API和依赖注入系统比我们想象的要酷多了。然而事实证明,AngularUI自带的select2下拉部件不能满足我们的需求,它在处理大数据集时变慢了。因此我们编写了Chosen的标识符(directive),该标识符可以工作在任意<select>元素上,并且与ngModel和ngOptions配合得非常好:
  1. <select
  2.   multiple
  3.   chosen
  4.   ng-model="state"
  5.   ng-options="s for s in states">
  6. </select>


经验教训

下面把我们从转型期所学到的,以及目前我们仍在努力解决的问题分享给大家:
  1. 标识符很难:处理好隔离范围和transclusion非常困难,AngularJS文档对这方面的帮助也不大。而编写出更小更突兀且能与其他标识符能够良好合作的标识符则是最好的。

  2. AngularJS文档需要多点爱:虽然我们能明白,但里面提供的学习内容还是不够全面。标识符和表单开发者指南目前是我们最好的伙伴。

  3. 表单验证不错,但仍需要些思考:我们的应用程序可以通过多页表单向导帮助用户创建有针对性的应用消息活动,所以表单模型验证是很棘手的事情。在实现上还需要一些反思,与此同时,我们也发现AngularJS似乎不支持单选按钮组的“required”验证,所以得添加一个隐藏的、且带有required属性的输入元素来对用户的选择进行验证。

  4. 声明(Declarative)是个好东西:在HTML和JavaScript上绕一圈后,我们觉得使用HTML和JavaScript开发交互式Web App是不错的选择。


常言道,实践是检验真理的唯一标准。我们从Backbone身上得出的结论是:“保持某块模板清洁”是一种反模式,它会使JavaScript代码与DOM之间的链接变得非常脆弱。Web开发是一项繁杂的业务,而简洁明了的代码则会让其变得非常轻松。而Angular就可以做到,它不但使我们的工作变得轻松,更是让代码量减少了一半,让我们有更多的时间去专注其他事情。(编译:张红月 责编:王然)
快速回复
限100 字节
如果您提交过一次失败了,可以用”恢复数据”来恢复帖子内容
 
上一个 下一个