AngularJS应用开发思维之1:声明式界面

时间:2024-01-05 20:06:44

这篇博客之前承接上一篇:http://www.cnblogs.com/xuema/p/4335180.html

重写示例:模板、指令和视图

AngularJS最显著的特点是用静态的HTML文档,就可以生成具有动态行为的页面。

还是前面的小时钟示例,我们使用AngularJS模板来重写,示例已经嵌入→_→:

示例地址:http://www.dwz.cn/26R4S5

HTML文件看起来像普通的HTML,只是其中多了一些特别的标记 (比如:ng-app,ez-clock等等)。在Angular中,这个HTML文件被称为模板。

ng-app这样的标记我们称之为指令。模板通过指令指示AngularJS进行必要的操作。 比如:ng-app指令用来通知AngularJS自动引导应用;ez-clock 指令用来通知AngularJS生成指定的时钟组件。

当AngularJS启动应用时,它会通过一个编译器解析处理这个模板文件,生成的结果就是: 视图。

我们定义了两个部件:模板(包含指令的HTML文件)和指令实现 (JavaScript文件),AngularJS将这两部分拼装起来,生成了最终的视图。

有点理解框架的含义了吗?

使用指令封装JavaScript代码

我们在模板中使用了一个自定义的标签ez-clock,而它变成了一个会动的时钟, 这期间发生了什么事情?

肯定不是浏览器干的,它不认识ez-clock是什么东西。

angular.min.js引入了基本的angularJS库,它会在浏览器载入HTML文档并且 建立好DOM树后,执行以下操作:

  1. 找到有ng-app属性的DOM节点
  2. 以这个节点为根节点,搜索自定义指令,发现ez-clock
  3. 调用ez-clock指令的实现函数(指令类工厂)进行展开

根据我们的定义,ez-clock的展开操作如下:

  1. 使用一个div元素替换这个自定义标签
  2. 创建一个定时器,在定时器触发时刷新div元素的innerText

ez-clock这样的非HTML标准标签,在AngularJS中之所以称为指令/directive, 就是指看到它时,基础框架需要对其进行解释,以便展开成浏览器可以理解 的东西(HTML元素和脚本),而这个解释的过程被称为:编译。

可见,AngularJS框架要求将HTML文档和JavaScript代码分割的更清晰,通常混杂在 HTML文档中的JavaScript代码,需要以指令的形式进行封装,而模板、指令 实现代码这两个部件,则由基础框架负责拼装运行。

将指令看做API

将DOM操作封装成指令,更容易进行分工与代码复用。

由于AngularJS更清晰地界定了一个WEB应用的组成部分,这样,在一个团队中,可以有人负责 实现指令,有人负责开发模板,各自干擅长的事情,效率更高,成本更低。

当然,从编写界面HTML模板的角度看,诸如ez-clock之类的指令比div更具有语义性, 使模板更容易维护,使指令的实现升级不影响模板,这也是不小的好处了。

与我们所熟悉的对象、函数这类接口完全不同,指令算是一种新型的API,它提供了在 静态化的HTML文件中,植入动态行为的能力:

定义自己的指令

AngularJS内置的指令不能完全满足实际开发的需要,通常我们需要定义自己的指令:

  • 增强标准DOM元素的行为

比如,希望一个DOM元素是可拖拽的,那么可以这样写:

  1. <p ez-draggable="true">...</p>

通过ez-draggable指令,我们赋予DOM元素可拖拽的能力。

  • 自定义组件

比如,我希望一个图片裁剪功能,那么可以这样写:

  1. <ez-photoshop src="a.jpg"></ez-photoshop>

通过ez-photoshop指令,我们定义了一个包含交互行为的web组件。

  • 封装其他组件库

这不是AngularJS鼓励的方向,但是确实有强劲的需求。

起点:声明化

基于前面的示例,我们容易感受到使用AngularJS进行应用开发的一个重要的思维模式: 从构造声明式界面入手。

事实上,我猜测这也是Misko开发AngularJS最初的动机。稍早一些的Flex、WPF和Firefox 的XUL,或多或少给了Misko启发。

在使用AngularJS进行前端开发时,始终应该从构造声明式界面模板开始,如果现成的指令不够 用,那么就定义自己的指令、实现自己的指令。这是一个迭代的过程。

记住,指令是新型的API,用界面的声明化作为需求,来指导我们的代码封装。

参考资料:http://www.dwz.cn/26R4S5