具有jQuery背景的程序员如何转换为AngularJS思考模式(译)

最近一直在研究angularjs,最大的感受就是它和之前的jQuery以及基于jQuery的各种库设计理念完全不同,如果不能认识到这点而对于之前做jQuery开发的程序员,去直接学习angularjs的话,很可能学了很久还不知道这个东西能用来干什么以及怎么使用,怎么和UI进行结合等问题,在stackoverflow上找到一篇关于这方面的文章,阅读之后颇有收获,在此基础上将它译成中文,以求抛砖引玉大家一同学习。

原问题:假如我熟悉利用jQuery去开发客户端应用,那么我怎么上手angularjs,能否描述下所需要的模式转变,下面这些问题能够帮助你给出一个回答:

1.在设计客户端web应用的时候有什么区别,最大的区别是什么?

2.我应该停止使用哪些技术,同时又使用哪些技术作为替代?

3.是否存在服务端需要考虑的东西或者说一些限制呢?

回答:

1.不要首先设计好你的页面,然后再通过DOM操作去修改它

在jQuery中,你首先设计了一个page,然后再去动态修改它的内容,这是因为jQuery被设计用来进行扩展并在这个前提下大幅度地增加和修改内容,但是在angularjs中,你必须在心中先设计好你的架构,

从一开始,你就要摒弃“我拥有一个DOM元素并且想让它去做某件事”,代之为“我需要完成什么任务,然后接着设计你的应用,最后再去设计你的视图view层”。

2.不要使用angularjs去扩展jQuery

相应地,不要存在说让jQuery去干某些事情,然后在此基础上添加angularjs的功能让它去管理model以及controller的想法。所以我一般不推荐AngularJS开发新手同时使用jQuery,至少在他们还没有适应AngularJS的开发模式之前不会去推荐这样做,但是当你真正开始适应angularjs 的方式之后,你会发觉这是一件很诱人的事情。

我曾经看到过很多开发者采用将150到200行代码的jQuery插件利用angularjs的回调以及$apply方法封装起来,这种方式使得代码看起来极其复杂,但是实际上他们让这些插件跑起来了!问题在于,在大部分情况下jQuery插件能够用angularjs进行重写,并且可能只会使用很少量的代码,同时这种重写使得代码很直观且易于理解,这显然好过于将jQuery代码直接做封装。

所以最后说,当你遇见问题的时候,首先要以angularjs的思维进行思考,如果找不到解决方案,可以求助于社区,如果说没有人能够给出一个简单的方案,那么才考虑使用jQuery,不要让jQuery成为你的拐杖,否则你永远掌握不了AngularJS。

3.要以架构为中心进行思考

首先你要知道单页应用属于web应用,它们不是传统的多网页网站,所以我们要同时作为一个服务端和客户端开发者的思维进行思考,我们需要思考如何将我们的应用分为独立的,可扩展的以及可测试的部分。

那么接下来我们如何采用AngularJS思维去工作呢,以下是一些将其与jQuery对比之后的基本准则:

以下是某个应用的视图层:

在jQuery中,我们动态地去修改这个视图,我们使用ul去定义一个dropdown menu

<ul class="main-menu">
    <li class="active">
        <a href="#/home">Home</a>
    </li>
    <li>
        <a href="#/menu1">Menu 1</a>
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li>
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li>
        <a href="#/home">Menu 2</a>
    </li>
</ul>

在jQuery中,我们采用如下逻辑使用这个dropdownMenu

$(‘.main-menu‘).dropdownMenu();

让我们回头看看这个view,你会发现它的功能并不是很直白,对于小型应用来讲,这样是可以的,但是对于大型应用来讲,这种方式会让人费解并且难以维护;

在angularjs中,这个视图实际上是一项基于视图的功能,我们可以这样来定义ul

<ul class="main-menu" dropdown-menu>
    ...
</ul>

这两种方式实际上做了同样的事情,但是在AngularJS方式下任何人看到这个视图模板就知道接下来要干什么。无论何时当一个新成员加入开发团队之后他都能够看到这里并发现这里有一个叫做dropdownMenu的指令去操作view,他不需要去猜想正确的答案或者审查其他的代码,这个视图就直接告诉我们它要做什么,相比于jQuery,它更为简洁。

常常有些AngularJS新手问这样的问题:我怎么才能找到某个确切类型的所有link并在此基础上添加一个directive,但是当我们回答了“你不应该这样去做,你这是一种半jQuery半angularjs的想法”时,他们会觉得很吃惊。

问题在于他们试图在AngularJS背景下用jQuery去做某件事,这通常不是一种好的方式,在指令之外你不需要去做任何dom操作,而指令是直接内添加在视图上的,所以意图已经很明显了。记住,不要先设计好之后再去修改,而是先有架构然后在这个框架下再去设计。

数据绑定

这是到目前为止AngularJS最令人瞩目的特性了,在数据绑定方面它舍弃了对DOM的操作方式,而这一切都是由AngularJS来自动更新视图,你不必写操作dom的代码,在jQuery中,我们常常按照以下方式响应事件并修改视图:

$.ajax({
  url: ‘/myEndpoint.json‘,
  success: function ( data, status ) {
    $(‘ul#log‘).append(‘<li>Data Received!</li>‘);
  }
});

相对于这样一个视图

<ul class="messages" id="log">
</ul>

除了混杂的问题之外,我们还存在我之前提到的如何表明自己意图的问题。但是更为重要的是,我们必须人工手动去引用并更新这个DOM节点,如果我们想删除其中一条,那么必须以编程方式去操作那个DOM元素,那么在这种情况下我们怎么去测试DOM节点之外的逻辑呢,亦或者我们想改变展示方式呢?

以上代码显得凌乱又脆弱,但是在AngularJS中,我们可以这样做:

$http( ‘/myEndpoint.json‘ ).then( function ( response ) {
    $scope.log.push( { msg: ‘Data Received!‘ } );
});

我们的视图应该像下面这样

<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

在那种情况下,我们的视图也可以这样

<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

现在我们不使用ul,而是使用Bootstrap的弹出框,但是我们不用修改controller中的代码,更为重要的是,不管是数据如何修改,视图层也会自动随之发生变化,非常简洁!

尽管我这里不会做演示,但是你需要知道数据绑定是双向的,你可以编辑数据通过添加指令<input ng-model="entry.msg" />,此外还有很多其他的令人兴奋的地方。

区别model层

在jQuery中,DOM类似于一种model,但是在AngularJS中,我们拥有不同于jQuery中的model层以便我们可以以任何我们想要的方式去管理它,它是完全独立于视图之外的。这种方式是有助于我们进行数据绑定并且可以保持对分离的关注,而且可以具备更好的可测试性。

关注点分离

以上所讲都和这个总体的话题相关:让你关注分离,你的视图层显示记录,你的model层代表数据,你还有个服务层用来执行这些可复用的任务。你使用directive来执行dom操作并扩展你的视图,并将它和controller连接起来,这也就是我在其他方面提到的有关于增强可测试性的原因。

依赖注入

帮助我们解决关注点分离的是依赖注入(DI),如果你是一个服务端开发者(Java或者PHP),你可能已经很熟悉这个概念了,但是如果你是从事客户端开发的,你会觉得这个概念可能有些多余和纯属追求时髦,但是实际上不是这样。

从广义的角度讲,DI意味着你可以自由地声明组件然后从这些组件中进行实例化,这是理所当然的。你不必知道加载顺序,文件位置等诸如此类的事情,这种魔力不是能够立即看到,但是我会给出一个例子:测试。

我们说在应用中,我们需要一个依赖于应用状态和本地存储的服务用来通过一个rest API来执行服务端存储,当我们测试我们的controller时,我们不必和服务端进行通信,毕竟只是在测试controller而已。我们仅添加一个与我们最初组件相同的mock服务,注入器能够确保我们的controller获得一个虚拟的服务,controller自身不必也不需要了解这种差异。

那么说说测试吧。

4.以测试驱动的开发

这部分是一个架构的第三部分,但是他是很重要的,以至于我需要将它放在最重要的位置。

在我们所有见过的,用过的以及写过的jQuery插件中,有多少具有一套测试组件呢?其实并不多,这是因为jQuery在测试上不易控制,但是AngularJS却与此不同。

在jQuery中,测试的唯一方法是使用一个demo页去创建一个独立组件来使得我们的测试可以执行dom操作。我们接下来我们必须开发一个独立的组件然后将它集成到我们的应用中来,这是多不方便啊!在很多情况下,当我们使用jQuery开发实际上是做了很多重复开发而不是以测试驱动的开发,这又能怪我们吗?

但是在AngularJS中我们可以关注分离点,所以我们可以做一些测试驱动的开发。例如,我们有一个directive用来说明在menu中我们的当前路径,我们可以在视图中这样声明:

<a href="/hello" when-active>Hello</a>

好了,现在我们可以写一个测试用来测试这个不存在的指令when-active了,

it( ‘should add "active" when the route changes‘, inject(function() {
    var elm = $compile( ‘<a href="/hello" when-active>Hello</a>‘ )( $scope );

    $location.path(‘/not-matching‘);
    expect( elm.hasClass(‘active‘) ).toBeFalsey();

    $location.path( ‘/hello‘ );
    expect( elm.hasClass(‘active‘) ).toBeTruthy();
}));

我们直接run测试用例,你会发现是失败的,这时候需要创建这个指令,如下:

.directive( ‘whenActive‘, function ( $location ) {
    return {
        scope: true,
        link: function ( scope, element, attrs ) {
            scope.$on( ‘$routeChangeSuccess‘, function () {
                if ( $location.path() == element.attr( ‘href‘ ) ) {
                    element.addClass( ‘active‘ );
                }
                else {
                    element.removeClass( ‘active‘ );
                }
            });
        }
    };
});

再次run这个测试用例,你会发现通过了并且菜单如请求的样子显示,我们的开发是兼有反复性和可测试性,非常酷吧!

5.从概念上讲,指令不是打包的jQuery

你常常听说,dom操作只能在指令中,这是必须的,你必须严肃对待。

让我们深入讨论,

某些指令仅仅是装饰我们的视图(例如ngClass),因此有时候直接操作dom是可以的,但是当一个指令类似于一个小物件并且拥有自己的模板,那么它应该当做一个分离的关注点,这就是说,它的模板需要和link中的执行逻辑以及其他controller函数分离开。

AngularJS拥有一整套的工具可以是这种分离更简单,使用ngClass指令,我们可以动态地更新class,使用ngBind我们可以进行双向数据绑定,使用ngShow和ngHide 我们

可以采用编程的形式显示和隐藏一个元素,也包括我们自己写的很多指令。换句话说,我们可以不用Dom操作而完成所有工作,dom操作越少,指令越容易测试,越容易指定他们的style属性,就越容易在将来改变他们

,那么他们就越容易复用和分发。

我看过很多AngularJS新手使用指令封装一大串 jQuery代码,换句话说,既然我不能在controller里面进行dom操作,那么我可以将他放在指令中,虽然这相对于直接操作dom好很多,但是任然是错误的。

看看我们在上面的记录,即使我们将其放在一个指令中,我们任然需要以Angular的方式去操作它,这种方式不执行dom操作!在很多时候dom操作是需要的,但是这种情况比你想的要少得多。当我们需要做dom操作的时候先问问自己这里是否必须这样做,这才是一种更好的方式。

下面是一个简单的例子用来表明我常常见到的一种模式,我们需要I一个可切换的button:

.directive( ‘myDirective‘, function () {
    return {
        template: ‘<a class="btn">Toggle me!</a>‘,
        link: function ( scope, element, attrs ) {
            var on = false;

            $(element).click( function () {
                on = !on;
                $(element).toggleClass(‘active‘, on);
            });
        }
    };
});

在以上例子中存在以下错误:

1.首先,jQuery是不必要的,这里的工作完全不需要jQuery!

2.第二,即使我们已经在页面中引入了jquery,但是我们没有理由去使用它,我们可以使用angular.element而我们的组件也能够运行,即使这个项目中没有引入jQuery。

3.第三,假设jquery是需要的在我们的指令中,我们可以使用jqLite去进行替代,只要引入jQuery即可,所以我们不必使用$而是使用angular.element;

4.第四,和第三点联系很紧密,jqLite元素不必使用$包裹起来,element元素传递到link函数中已经是一个jQuery对象了;

5.第五,我们之前已经说过,为什么不将我们的模板和逻辑混合起来呢?

以上指令可以按照如下方式来重写,即使在最复杂的情况下看起来也如此简单。

.directive( ‘myDirective‘, function () {
    return {
        scope: true,
        template: ‘<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>‘,
        link: function ( scope, element, attrs ) {
            scope.on = false;

            scope.toggle = function () {
                scope.on = !scope.on;
            };
        }
    };
});

模板元素是在 template属性中,你可以很容易替换掉它的style,而逻辑根本不用发生变化,达到了完全复用!

还有其他的好处,比如测试起来很简单,不管模板里面是什么,指令API都不会发生改变,所以重构它很简单。你可以随意多次改变你的模板而不用改变指令,无论你怎么改变,你的测试总能通过!

所以说指令不是一堆jQuery代码的集合,比如函数等,而是HTML代码的扩展,如果HTML代码不能实现你需要的功能,你可以写一个指令去实现它,然后像使用HTML那样去使用它。

以另外一种方式讲,AngularJS如果不做额外的事情,想想我们怎么能够使用ngClick,ngClass指令呢?

总结

不要总使用jquery ,甚至不要去引用它,它会阻止你前进,当我们回到这个问题—你知道你怎么在AngularJS中以jquery方式解决问题,但是当你使用诸如$等选择器时,你要想想它们实际上是禁锢了AngularJS,如果你不知道怎么不用jQuery实现,那么去请教别人,一次一次去问,最好的方式是不需要使用jQuery,使用jQuery只会导致你的工作量提升。

时间: 2024-08-04 17:00:56

具有jQuery背景的程序员如何转换为AngularJS思考模式(译)的相关文章

android程序员成长路径的思考

我之前就想过要写这个话题,不过之前没有什么认识,我只是在阅读别人的见解,看法.昨天晚上,我阅读了这篇文章<产品经理罗永浩:用户体验探索,没有尽头>,这篇文章描述了罗永浩对锤子手机设计细节的阐述,及罗永浩对产品经理的看法,认识.恰巧阅读了这篇文章,我从中想到了android程序员的成长路径. 成长路径之一,可以做出产品经理要求的各种界面效果. android程序员,是做android系统上的应用的,一个应用就是一个产品.我是这样认为的,你可以做出好的产品,那么,你就是优秀的android程序员.

一个程序员对互联网的思考

时间匆匆,转眼间,在IT行业已经瞎混了足足两年的时光,在这期间,有过快乐,有过悲伤,想过放弃,想过转行,想过不做北漂,挣扎过,逃避过,思考过,不管过程是如此的不堪回首和煎熬,总之,我熬过了IT行业的入门级别的经验. 能够在这有空的时间去思考些自己思想,我觉得是自己提升,不仅可以分享下自己的事情,还可以帮助下要入行的,或者还在挣扎的同行们,可以一起共勉,一起进步. 下面就让我随便聊聊我两年时间内的成长和进步吧. 从13年7月离开校园,踏上北上的列车,就注定了自己要做一个北漂的流浪人,我是带着梦想和

程序员的学习方法【思考】

程序员的学习方法 作为IT业的一员,我们几乎每天都有大量的知识需要学习,有大量的技能等待我们去掌握.几乎从我决定"献身"程序员这一伟大事业之后,我就一直在考虑怎么提高自身的学习的能力(简称学习力),以下两张图作为我多年学习生涯得来的宝贵经验,拿出来和同学们分享.   如果你看到的第一张是埃及的金字塔,第二张是中国的太极图,说明我的图片没错:第一张代表"知识的金子塔结构",第二张说明了"理论和实践的相生相克原理". 一.知识的金字塔结构.我把我了解

【转】关于程序员成长的一点思考

新闻来源:51CTO 程序员的我们,是否想过今后的路该怎么走.如何发展.技术怎样提高?其实这也是我一直在思考的问题.下面就此问题,分享下我的看法.因为我阅历有限,有什么说的不对的,大家一起喷! 一.程序员应该打好基础 1. 现在开发工具众多.语言泛滥,经常听人说”不学C C++神马都是浮云”.”C C++才是万王之王”,C C++就真比PHP.Lua.AS.JAVA牛吗? 其实不在于语言本身,而在于C C++依附的平台.因为最靠近操作系统,所以能发挥其它语言不具有的性能优势,而且很多数据结构.算

最近对程序员精神境界的思考

曾经我是一个做windows mobile智能手机开发的软件工程师,我接触并学习了VC++,Win32,WTL等技术知识,这些技术知识都是围绕着微软的Windows体系的.我在追求精神信仰的时候,认为Windows即可是我程序员生涯中的信仰. 而这一切在2010年开始发生改变.2010年android表现出很猛的发展势头,我被安排做android开发而抛弃了windows mobile的开发. 直到现在,5年时间内,我又接触并学习了很多围绕android的知识体系.其中,我阅读了<running

关于程序员成长的一点思考

一.程序员应该打好基础 1. 现在开发工具众多.语言泛滥,经常听人说”不学C++神马都是浮云”.”C++才是万王之王”,C++就真比PHP.Lua.AS.JAVA牛吗? 其实不在于语言本身,而在于C++依附的平台.因为最靠近操作系统,所以能发挥其它语言不具有的性能优势,而且很多数据结构.算法.特殊功能类,C++是不提供的,需要自己实现.这时就需要自己去温习”数据结构”.”算法”.”TCP/IP”.”操作系统原理”.”编译原理”等这些知识.正因为如此,我们学习的东西被沉淀下来,也正因如此,C++经

一个程序员对职业生涯的思考

写这篇文章源于某条微博评论,原内容大概是一个快40岁的人还在当程序员写代码,评论内容大概是:有些人就喜欢当程序员写代码,无可厚非.但是,现实情况中是否真的能做到“无可厚非”呢?我思考了一阵子以后,就有了这篇文章,希望与所有职场人共勉. 首先我要申明一点,我不是砖家,也不是牛人,我只是一名普通的IT从业者,本文只是我对我们IT人的职业生涯规划的一些观点和意见,如果大家有不同意见,或者觉得我的观念欠妥,欢迎讨论,但是拒绝谩骂.吵架和攻击,谢谢. 简单介绍一下我的情况,我是03级的本科生,07年毕业后

程序员更需要深度思考~宅客学院

这是一个人人都在学习编程的时代:Code.org请了比尔·盖茨,马克·扎克伯格和克里斯·波什等这些名人,来告诉你,每个人都可以编程:CoderDojo’s在各个国家悄然兴起:在英国,编程已经是各个年级学生的正式课程. 我认为这里有个误区.别误会我——如果每个人都会一些编程知识,这个世界当然会变得更好——但是学会写代码不应该是我们的目标.计算机和程序只是一个工具,是一种达到某种目的的方法. 真正的目标应该是学会思考的方式.换句话说,我们应该尝试教授计算机科学,而不是教着写代码.在本文中,我将介绍两

关于程序员的几点思考

前几天读了一篇<什么是真正的程序员>,以小王子中的口味讲述了 printf 遇到各种各样程序员的故事,引起了我一些思考,并不只是对程序员实用.需要看这篇文章请点击最后「阅读原文」. 1. 应不应该专注于一个领域? 我认为一个人在一个领域里要有所成就专注是必须的.专注并不是说重复做相同的事情,应该是持续不断的收集与整理,因为每次的变化如此微小以至于你完全感觉不到自己的进步,这会让人很沮丧,也是大多数人无法持续专注的原因.因为没有让自己耳目一新的观念和知识刺激自己,时间久了会相当疲惫.而且随着研究