本书包含了构建常用JavaScript组件的基础知识,并通过实例带领你学习组件的概念化、设计和实施,后半部分则涵盖了封装、打包和部署的相关知识。无论你是缺乏组件使用经验的JavaScript开发人员,还是具有组件库的丰富使用经验、想创建出定制组件的前端开发人员,这本书都适合你阅读。
√ 全球首部关于Google Polymer 新型UI构建框架的技术书籍
√ Web组件技术是前端开发的大势所趋,所有新技术都由此发端,关于这个话题也只有本书涉及
√ 本书提供详尽实战案例,介绍了全新Web组件开发的思路和流程
前言
为什么写这本书
13年前,我进入了Web开发领域。这13年来,Web开发技术的进化一刻都未停止过,而且,其进化的速度正在逐渐加快。如果你了解一下,Google 在 Polymer 和 Web 组件技术中的投入,你多半会认为,在不久的将来,随着浏览器技术的进步,Web 组件将在 Web开发领域占据一席之地。虽然目前 Web 组件还有一些需要解决的问题,比如搜索引擎优化(SEO)等,但我认为这不会阻碍 Web 组件的发展,我甚至认为这不是一件坏事。在Web 开发领域,Web 组件技术(或具有类似关于继承、构建、封装、依赖的标准的技术)已经被期盼已久。即使你不太关心 Web 组件,那么看看这个领域的牛人们是如何实现自己的 UI 库(比如,使一个元素可拖拽之类),也没有坏处。
GlennVanderburg说:“开发者应该理解自己日常工作之下的抽象层。”我赞同这句话,而且我认为,对于大部分前端工程师,这一层抽象层通常就是指控件库,以及 jQuery 插件甚至 jQuery 本身,因为大部分前端工程师的日常工作就是跟这些工具打交道。这一层抽象层中,包含控件库所进行的 DOM 操作、DOM 本身及其原生 API。理解这些库是怎么工作的,会帮助你写出高效的代码,帮助你提升。
有时候,这些常用的库并不能很好地适用你面临的具体情形(你的产品经理或信息技术官将此情形抛给你处理),这时,如果你不会“游泳”,就会“溺水而亡”。我想,提前学习一些“游泳”课程(也就是本书了),会让你在那一天到来之时不那么手忙脚乱。而我,就没你那么幸运了。
我曾经负责制作一个定宽的门户产品,其中每一个门户组件都是可以调整大小的。听上去很简单,是吗?首先,我被告知在我之前的 Web 开发者曾经尝试完成这个功能,但是都失败了,他们说这是不可完成的。好吧,听上去很挑战。当时 IE9 刚刚进入市场,因为之前的“技术债”,我们运行着三个不同版本的 jQuery 和两套不同版本的 jQuery UI,没有一个组合能够很好地适配 IE9。于是,我工作的第一步,就是将站点使用的 jQuery统一到一个版本,并适配 IE9。你也许认为,统一 jQuery 的版本非常简单,但刚刚接手,我就意识到为什么我们欠下了那么多的“技术债”。我们的站点上运行着大量新旧混杂、良莠不齐的 jQuery 插件。升级 jQuery 伴随着对这些插件的升级,以及打破了现有的代码体系。我对一些插件进行了升级或者修补,而更换了另外一些插件。这个过程需要对DOM 的深入了解,当时我并不具备。我在控制台输出日志进行调试,在 Stack Overflow(http://stackoverflow.com)寻求帮助,甚至进行逆向工程,最终解决了每一个问题。而这,仅仅是在开始开发新功能(门户组件可调整尺寸)之前所做的准备工作。
接下来,我收到了一个可笑的需求,就是门户组件列的调整,只能精确地调整为某些预设好的尺寸,而不能随意调整。当时并没有一个插件能够满足这个要求,于是我编写了自己的插件。
当我把(意大利面条似的)插件代码写完之后,我就需要应用插件使每一个门户组件可被调整大小。各种鼠标事件必须协同起来,保证拖拽的时候不会从外层容器中溢出。从此我爱上了 setTimeout ,直至今天。
如果你对我的故事感同身受,那么你自己一定也有类似的故事。就像我一样,你把各种Stack Overflow 上获得的代码片段、各式 jQuery 插件,用自己的“胶水代码”粘在一起,你需要 100 个不同的分支,处理各种各样的异常,这些异常均因为你对内在机制缺乏了解而造成的。我也曾经处于那种情境下,那一点都不好玩。所以,我用自己的经验写下
了这本书。
这本书除了能让你避免“溺水而亡”,还能帮助你了解 UI 组件功能的底层细节。
? 本书允许你定义对自己有意义的 API,因为 jQuery 插件并不适用每一个人。
? 让你拥有整个技术栈的控制,方便你调试,允许你自己决定某些变化发生在哪个层面。
? 允许你自己决定哪些特性是重要的,哪些是不必要的,以控制代码的体积。这在对代码体积比较关心的场合(如手机应用)很有用。
? 允许你针对自己的应用和用户场景做额外的优化。
最后,我认为每个前端工程师都应该理解原生 DOM 和 JavaScript。这份理解,和设计方案的能力,是优秀的前端工程师所必须的。
本书包含什么
本书编写的最初目的,是向读者传授基础知识,用以开发和部署 Web 组件。本书更像是入门教程,而不是详尽、彻底的教科书。本书中的知识被分为四个部分,每个部分为一篇,每一篇又分几个章节,全部是围绕一份项目代码编写的。
第 I 部分 UI 核心概念
第 I 部分的内容包含了诸如克隆节点、渲染图层、堆叠上下文,以及 z-index 的相关知识,理解这些知识能帮助我们对页面上的元素进行定位、拖拽和尺寸调整。这些概念经常被开发者误解(或不完全理解),进而导致不佳的软件设计和实现,影响应用的性能与代码的可维护性。如果你对这些概念已经了如指掌,那么也可以跳过第 I 部分。
第 I 部分,我们将引入一个组件基类(它会派生出对话框控件类)。组件基类和对话框将贯穿本书的其余部分。如果你跳过了第I部分,但又想了解一下组件基类的细节,可以快速回顾一下第 ?2 章。
第 II 部分 构建 UI
本书第II部分介绍了当下前端类库,如Dojo (http://dojotoolkit.org)、jQueryUI (http://jqueryui.com)、KendoUI (http://www.kendoui.com)、TwitterBootstrap (http://getbootstrap.com)遵循的概念和模式。你日常工作中用到的UI组件,可能就是遵循这些概念和模式实现出来的。
如果不深入其中,这些抽象和UI组件提供的好处是很难理解的。我强烈建议前端工程师使用一个提供了良好生命周期、继承模式、工具函数和工具类的基础库,比如jQueryUI。
如果你想追寻一个更轻量级的库,那么你可以了解一下 jQuery++(http://jquerypp.com),这个库提供了拖拽、调整尺寸等功能,代码体积仅为 162KB。它也允许你挑选其中的部分特性生成一份代码,以进一步减少库的代码体积。
本书将实现一个对话框组件,实现该组件的过程就是实践上述概念和模式的过程。
如果你对这些模式都非常清楚,想更深入地研究 Web 组件,那么也可以从第 ?III 部分开始。
第 III 部分 构建 HTML5 Web 组件
本书的第 III 部分,介绍了由 W3C 定义、浏览器实现的 Web 组件技术。这一部分使用了前两部分编写的对话框控件,将其转化为一个功能全面的 Web 组件。
第 IV 部分 使用 Polymer 测试,构建,部署 Web 组件
本书的第IV部分涵盖了如何使用Google的Polymer (http://www.polymer-project.org)桥接Web组件技术与当前浏览器环境。Polymer 提供了方便的API,便于你创建可扩展的 Web组件。这一部分,还将指导你将第 ?III 部分编写的对话框 Web 组件转化为一个 Polymer组件。最后,本书还会介绍如何使用构建工具和包管理工具打包和部署 Web 组件(包括Polymer 化版本的组件)。
本书不包含什么
本书的目的不是成为一份开发 Web 组件的“权威指南”,教会你在任何能够访问互联网的设备上开发 Web 组件。因为以下两个原因,这几乎是不可能的。
首先,这几年浏览器性能正在飞速的提升,而 Internet 也从一个“文档传递”网络逐渐变成了一个准应用平台。在这个转变的过程中,浏览器变得更加稳定,具有了更多丰富的特性。在编写表格布局的页面和使用 Netscape 4 进行测试的年代里,这是不敢想象的事情。很多原本需要使用 JavaScript 实现的功能,现在只需要 CSS 就能够完成了。然而问题是,虽然 Web 的标准在进化,但浏览器并没能完全跟上,或者说不同浏览器对新特性的实现进度并不一致。浏览器的引擎,是浏览器厂商自己基于 W3C 标准而实现的,不同厂商的实现细节自然不一样。这些新的特性,对于 Web 组件开发来说尤为重要,但是浏览器世界是一个新的主题,一本书也不一定说得完,更不可能在本书中讨论清楚浏览器问题的细节了。而且当你开发 Web 组件的时候,哪些浏览器支持哪些不支持,这些也不是最重要的。
其次,这五年来,能够访问互联网的设备,其数量和种类(手机,平板电脑等)也在飞速增长。新设备的进化和增长,以及设备厂商的努力,使得之前的诸如有限的处理器性能、有限的存储空间、较小的屏幕、较差的网络连接等问题得到了解决。新设备给 Web开发领域的影响是有趣的,也带来了一些新概念和新模式,如响应式布局设计、触摸和手势事件,等等。但是,每个设备都有自己的“怪癖”,不断增长的移动设备市场,也会给 Web 开发领域带来新的课题。但是,这个课题本书也并不会涉及。
试图在一本书中同时解释清楚这些复杂的问题,几乎是不可能的。本书的内容比《计算机编程艺术》还要宽泛,但是在第一章写完之前,也许就过时了。
除了关于市场上设备数量和功能的问题,你还需要知道的是,W3C 制定的Web 组件标准仍然在发展中。因此,本书中包含的内容,也许很快就会过时。等 Web 组件标准制定好之后,会再出一版新版。我将尽最大的可能紧紧跟随标准。
致谢
Jason Strimpel
首先,我要感谢我的妻子Lasca对我的鼓励和理解。我无法想象比她更好的人生伴侣,也没有见过另一个像他这样聪慧、美丽和特别的人。我爱你,你是我的一切。
我还要感谢我的老板 Claude Jones,他帮助和指导我完成了本书。没有他,就没有这本书的存在。
我还要感谢本书的另一位作者 Jarrod Overson,他答应编写本书的第 IV 部分。如果本书有什么不恰当的地方,那一定是我的责任。跟我相比,你是一位更有天赋的作者、演说家和工程师。
此外,我还要感谢 Simon St.Laurent,他倾听了我的不成熟的想法,并给出了很好的建议,这些建议帮助我把这些想法最终转化为了本书。同样,本书的编辑 Brian Anderson,他是我见过的最耐心的人。如果没有他,本书只会是一堆没有上下文,无法被其他人理解的手稿。谢谢你,Brian。
最后,我还要感谢本书的“隐秘合伙人”:社区中的那些编程牛人。他们的编程水平远超于我,教会了我无数的知识和经验。他们从公众视野中为我们选择出了最精华的部分。
如果你足够幸运,能够与他们共事,那么请相信我,你一定会马上发现(他们是真正的牛人),并听从他们的经验。正是因为他们,我才能够从一个资质平平的开发者成长为一名工程师,才能够分享我拥有的这些知识。
Jarrod Overson
如果没有我耐心的妻子,Kate Lane,我在本书中的工作根本无法完成。这些年,她已经习惯于听我唠唠叨叨地讲述那些关于JavaScript体系和物理模拟的话题,默默支持我,还能保持好奇心。是你的支持,使我能够安心出国演、写代码到深夜、花费很多时间组织社区事务。没有你的支持,就没有我所拥有的一切,包括我们的两个可爱的孩子。
谢谢你 Finn,你为我的生活带来了太多的乐趣。作为你的父亲,我常常被你的天才想法所惊讶和激动。同样谢谢你 Norah,你总能够让我抛却烦恼。你们两个是我的骄傲和前进的动力。
最后,谢谢你 Jason。你在编写本书的时候想到了我,你是 San Diego 最优秀的开发者之一,与你共事是我的荣耀。希望在将来,能够与你有更多的合作。