• react+redux+koa技术栈实现小结

      虽然别人整理的入门知识资料已经挺多的了,但不一定适合自己,还是重新整理下,理一理React的开发生态。 一、React 安装使用   使用react,只需要引入react.min.js(React 的核心库)和react-dom.min.js(提供与 DOM 相关的功能)即可。 1 2 3 4 5 6 7 8 9 10 11<script src="../js/lib/react.min.js"></script> <script src="../js/lib/react-dom.min.js"></script> <div id="example"></div> <script type="text/babel"> ReactDOM.render( <h1>Hello, world!</h1>, document.getElementById('example') ); // 这段代码将一个h1标题,插入id="example"节点中 </script> 通常为了使用JSX语法,我们需要在文件打包时使用插件将含有JSX语法的文件解析成普通的JavaScript语法,例如fis3-parser-react;如果使用到了ES6的写法,也需要将其转为ES5的格式,例如使用fis3-parser-babel。(现在前端已经不用ES6了,babel太慢影响效率,ES6在Node上使用) 二、React JSX   React使用JSX来替代常规的 JavaScript,以为JSX执行时进行了优化,含有错误检测而且方便我们书写模板。 1 2 3 4 5 6 7 8 9 10 11 12var...


  • 聊聊未来的前端时代

      2016年结束了,前端技术的发展也将进入到一个新的阶段,那么未来又会给我们带来什么呢?这里就个人发表下意见,不喜勿喷。   就前端主流技术框架的发展而言,过去的几年里发展极快,在填补原有技术框架空白和不足的同时也渐渐趋于成熟。未来前端在已经趋向成熟的技术方向上面将会慢慢稳定下来,并进入技术迭代优化阶段,例如语言标准、前端框架等。但这并不代表前端领域技术就此稳定了,因为新的技术方向已经出现,并在等待着下一个风口的到来。那么什么是下一个风口?虚拟现实?人工智能?或者其它的?不管未来如何,就前端应用开发方向来讲,MVVM、Virtual DOM和同构的技术解决方案依然会延续发展一段时间。而且这段时间内前端框架技术的变化将不会像原来一样具有颠覆性。   当 MVVM、Virtual DOM或同构等技术实践都有很成熟高效的框架和方案去实现了。那么对于移动端应用,前端要重点发展的下一步可能就是MNV的原生NativeView开发,例如使用通用的MNV前端技术实现方案来降低移动端Native和前端Web交互的开发成本,让前端既可以通过Native编译开发出稳定的原生应用外壳,也可用来开发快速迭代、高性能的移动端MNV*应用,最终形成一套移动端上高效率的前端开发生态体系。   另一方面,新领域的Web化思路也会给前端带来新的技术革新和发展机遇,例如Web VR(Virtual Reality,虚拟现实)、物联网(Physical Web,顾名思义,就是将物体连入网络的一种理念)Web化或者网站人工智能等,这些方向的开发者早已跃跃欲试,目前国外也能找到少数这样的应用站点。 1. 未来前端趋势   经过近几年的发展,现代前端已经发展到跨端、跨界面的革新阶段,目前主流以基于MVVM、Virtual DOM、移动端MNV*思路和前后端同构技术进行开发的项目居多,实现的方向也多种多样,这些我们前面对应的章节也均有讲到。当然除了这些,关于未来,还有一些我们前端工程师需要了解的,那我们就一起来看下未来前端具体可能会发展成怎样的呢。 1.1 新标准的进化与稳定   前端新标准和草案在不断更新,HTML、CSS、JavaScript标准也在渐渐完善,尽管这些新的规范最终会淘汰旧标准的使用,新的项目也会以最新的标准作为开发依据,但要完全停止旧标准的使用并完成企业级旧项目的升级,依然需要一段时间。例如原有CoffeeScript的项目不可能一次性的做出迁移重构,但我们的项目仍需要维护,我们不能脱离实际项目去谈技术,这就需要一段时间来慢慢修改;再如Web Component现在也不会马上作为唯一标准大力推广。但可以肯定的是,新的语言或技术标准一定会被推广使用,只是还需要时间。   同时基于标准也会出现一些衍生的脚本语法和规范来适应特定的应用场景,这些非标准的规范除了解决具体业务技术问题之外,极有可能进化成下个标准的一部分或被新的标准借鉴。例如CoffeeScript虽然最终没有形成JavaScript开发标准,但EcmaScript 6却借鉴了其中很多优秀的特性;或者目前生成Virtual DOM的衍生脚本语法,未来也是有可能被列入到JavaScript标准当中的。   经过大版本的更新稳定,目前前端三层结构实现已经形成了HTML5、CSS3、EcmaScript 6+标准规范结合的阶段,后面标准的新变化也会越来越小,至少迄今为止,我们无法预见HTML6的到来、CSS4的特性目前也令人担忧、EcmaScript 7的特性更新也并不明显,这都显示出,目前前端项目实践规范将会相对稳定一段较长的时间,后面的修改不会像之前一样具有颠覆性,这也是技术标准发展到一定成熟阶段会发生的事情。 1.2 应用开发技术趋于稳定并将等待下一次革新   从前端应用开发框架上来看,先后经历了DOM API、MVC、MVP、MVVM、Virtual DOM、MNV*阶段,逐步解决了前端开发效率、设计模式、DOM交互性能的问题。这些问题处理完成后,相关的框架也会进入稳定发展、版本有序迭代的时期。也就是说前端的交互框架不会像以前那样变化频繁,相对于之前前端框架的频繁更换到现在主流框架的稳定升级,我们可以看出这点。但目前前端可能还有一件需要去做的事情,那就是使用前端技术栈独立开发Native应用的能力,如果做到这点,前端开发者就可以结合MNV开发模式独立进行Native应用开发并快速实现高性能的移动端应用了。因为目前的MNV框架的设计实现依然依赖已有少数几个成熟Native应用的运行环境,还做不到在通用的APP上用前端技术栈直接调用移动设备原生API。但如果前端技术栈具备了通用的Native开发能力,技术上也就意味着,JavaScript脚本(或是衍生的其它脚本)可以将任何一个普通的移动端应用编译打成为Native包,并能使用MNV*模式直接与移动设备原生API进行交互。目前也有框架实现在做这方面的尝试,但还不是很理想,仍需要更多的改进完善。但无论如何,前端技术栈的Native开发实现技术必将成为前端的下一个实践核心。 1.3 持续不断的技术工具探索   前端技术效率和性能的提升当然不是仅靠前端框架都能解决的,还需要其他各方面辅助工具的支持,例如高效的调试工具、构建自动化工具、自动发布部署工具等。所以未来前端发展过程中各种高效工具的探索仍会不断地出现,来解决特定场景下的问题,最后进行一个优胜劣汰的过程。 1.4 浏览器平台新特性的应用   就浏览器端应用而言,以Chrome为代表的浏览器版本和特性发展迭代极其迅速,经过多版本的迭代,浏览器上已经可以实现较多的增强和实用特性,例如Web Component、Service Worker、IndexDB、WebAssembly、WebRTC、EcmaScript 6+的支持等等,但由于浏览器的种类和版本的多样性,我们还不能在业务中直接推广使用这些新的特性,但这些却仍然给了我们很多未来技术实现的可能,并且未来较多技术也会在这些新特性的基础上优化或改进产生。 1.5 更优化的前端技术开发生态   贯穿浏览器、服务端和移动端,前端正朝着多端、多技术实现的方向发展。这意味着前端这套技术栈能做的事情可能更多,涉及的平台更广,但作为整套技术开发生态的一部分,每一项技术的出现都必不可少的要去考虑开发效率、维护成本、性能、扩展性这几个方面的问题,所以寻找并发展更优的开发生态体系仍是前端未来的大方向,对于新技术的出现,我们也会从下面几个方面去评价它的意义。 开发效率。通常提高开发效率的方式就是使用开发框架。例如DOM编程框架的实现,简化了脚本API的使用、提高了代码复用性,选择好的框架常常能够让我们的工作事半功倍。 维护成本。使用框架提高了项目的开发效率,但却并不能解决代码维护性的问题。这就需要借助合适的模式来管理项目开发的代码,降低项目的维护成本,例如提取公共业务基础库、模块化、组件化等。目前可能最佳的实践就是组件化了,让业务模块的实现和管理有章可循,同时这也是Web标准未来发展的需要。 性能。从前端开发框架的演进来说,可以总结为先专注于解决前端的开发效率问题,然后解决前端的交互性能问题,再去尝试打通Native开发的能力。所以性能将作为未来评价任何一个框架或技术优劣性的重要标准而存在,同时性能也将是一个无法避开的永久性话题。 扩展性。其实扩展性不只是讲框架的方便定制和扩展特性,还要做到能与原来的技术框架相兼容并解耦合。很实际的场景,例如要使用某个新技术对原有的业务做改造,我们不可能马上就替换掉所有的业务模块,那么就不能因为新增加的技术框架实现而导致旧的模块运行出现问题。所以在新技术的应用中,除了保证原有业务层的扩展兼容,实现功能的平滑过渡也是一个必须考虑的问题。 1.6 前端新领域的出现 除了目前浏览器、服务器、移动端上的应用开发技术变革和探索外,未来前端也会出现新的应用场景。例如VR、物联网Web化、Web人工智能等。这些虽然听着比较远,但一旦到来就会很快被使用,所以前端不仅自身发展快,推广使用也极其迅速,例如移动互联网Web的普及也就两三年时间。 近几年,Web VR和物联网Web化的概念渐渐出现,国外甚至出现了以人工智能为支撑的Web应用。...


  • 前端自动化测试解决方案探析

      前端测试一直是前端项目开发过程中机器重要的一个环节,高效的测试方法可以减少我们进行代码自测的时间,提高我们的开发效率,如果你的代码涉及的测试用例较多,而且项目需要长期维护,这时就可以考虑使用一下自动化测试了。 一、前端自动化测试   前端自动化测试一般是指是在预设条件下运行前端页面或逻辑模块,评估运行结果。预设条件应包括正常条件和异常条件,以达到自动运行测试过程、减少或避免人工干预测试的目的。在前端自动化测试中,我们通常是通过不同的工具来解决不同场景下不同的问题的。就测试类型来看,主要分为BDD(Bebavior Driven Developement,行为驱动测试)和TDD(Testing Driven Developement,测试驱动开发)。BDD可以让项目成员(甚至是不懂编程的)使用自然描述语言来描述系统功能和业务逻辑,从而根据这些描述步骤进行系统自动化的测试;TDD则要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速实际开发过程   BDD和TDD均有各自的适用场景,BDD一般更偏向于系统功能和业务逻辑的自动化测试设计,而TDD在快速开发并测试功能模块的过程中则更加高效,以快速完成开发为目的。下面我们看下BDD和TDD具体的特点: BDD的特点: - 从业务逻辑的角度定义具体的输入与预期输出,以及可衡量的目标; - 尽可能覆盖所有的测试用例情况; - 描述一系列可执行的行为,根据业务的分析来定义预期输出。例如,expect, should, assert; - 设定关键的测试通过节点输出提示,便于测试人员理解; - 最大程度的交付出符合用户期望的产品,避免输出不一致带来的问题。 TDD的特点: - 需求分析,快速编写对应的输入输出测试脚本; - 实现代码让测试为成功; - 重构,然后重复测试,最终让程序符合所有要求。 二、单元测试解决方案   就前端而言,单元测试的实现工具比较多。主要有mocha,jasmine和qunit。我们先来看看使用mocha是怎样实现单元测试的。 mocha   mocha的特点是简单可扩展、支持浏览器和Node、支持同步和异步、支持连续用例测试。测试集,以函数describe(string, function)封装;测试用例,以it(string, function)函数封装,它包含2个参数;断言,以assert语句表示,返回true或false。另外,mocha在完成异步测试用例时通过done()来标记。 1 2 3$ npm install mocha $ mkdir test $ $EDITOR test/test.js # or open with...


  • 【原译】使用MobX怎样管理JavaScript应用状态

      【译者注】:这是mobxjs的一名作者写的mobx使用解析,读完觉得挺有意思。   如果你曾经用jQuery写过复杂的应用,你可能就会遇到管理不同页面部分UI内容同步的问题。常常,数据修改后需要体现在多个地方,随着项目的复杂化,你可能很难去管理。为了解决这个问题,我们常常需要使用事件来让页面的多个部分知道数据改变了。   所以,现在你是怎样管理这个状态的问题的呢?我确定你是通过订阅的方式来做的。这是对的,我敢肯定,如果你没有使用订阅的方式,那你实现起来太辛苦了,除非你使用了MobX。 什么是状态?   这里是一个person对象,比如某个人,他有firstName,lastName和age,另外fullName()方法将显示他的全名。 1 2 3 4 5 6 7 8var person = { firstName: 'Matt', lastName: 'Ruby', age: 37, fullName: function () { this.firstName + ' ' + this.lastName; } };   那么当这个人的信息修改时,是怎样体现到你输出内容上的呢?你在什么时候触发这些通知呢?在MobX之前,你可以使用setter来触发jQuery事件或者js信号。这些方案很好,但是使用它们不够清晰。我想在person对象的任何部分改变时就去自动触发。   这里是一段修改firstName信息的代码,如果我修改age,那么这是会触发修改通知的,因为我们将数据订阅绑定在person的整个对象上了。 1 2 3 4 5 6 7 8 9 10 11 12person.events = {};...


  • 理解ionic2 + angular2开发方案

      看了下ionic2的官方文档,做了简单的分析理解。 1. 安装使用   ionic2的安装运行基本和前版本的ionic基本一致,非常简单。 1 2 3 4npm install -g ionic # 安装ionic工具集 ionic start projectName --v2 # --v2表示使用ionic2 + angular2的组合方式创建项目,否则使用ionic + angular创建项目,此时ionic会下载所需要的相关包 cd projectName # 进入创建的项目名称目录 ionic serve # 启用浏览器调试应用页面,这时通过浏览器打开默认端口页面http://localhost:8100/#/tab/dash就可以打开应用页面了 当然这里需要保证你的开发环境SDK已经安装成功了,例如Android打包平台的运行环境,可以参考Ionic Hybrid跨终端应用程序开发方案研究   如果需要在移动设备上打包运行,则需要添加相对应的插件模块。 1 2 3 4 5npm install -g cordova # 如果没有真实设备,可以通过这个命令来安装模拟环境 ionic platform add ios # 添加ios运行支持...


  • mnv*框架开发时代

      当下前端开发框架设计显然已经在mvvm方式上又发展了一步,virtual dom提出不久,使用前端代码来调用native的思路就开始被实践。相信大家也知道是什么东西。到了今天,我们不得不承认,mnv* 框架开发时代已经到来。   mnv*是什么,具体可以这么理解,model-Native-View-*,而后面的*则可以认为是 virtual dom 或 mvvm 中的 ViewModel,或者我们也可以自己使用controller来实现的调用方式。想想这样定义是非常合适的。相比之前的不同,就是用 nativeView代替了 htmlView。那么我们再看看下从dom api 到 mnv*,我们为什么会看到这样的变化。 一、dom交互   在此之前不得不提下之前的dom交互框架,就是直接选择找到特定的dom进行操作,思路十分直接也很实用,通过dom交互框架,相比JavaScript原生API,我们可以比较高效的处理dom的改变和事件绑定了,这种高效的方式给我们到来了效率上的提高,但是页面复杂了就不好处理了。   随着ajax技术的盛行,SPA应用开始被广泛运用。SPA的引入将整个应用的内容都在一个页面中进行异步交互。这样,原有的dom交互方式开发就显得不好管理,例如某SPA页面上交互和异步加载的内容很多,我们的做法是每一次请求渲染后做事件绑定,异步请求后再做另一部分事件绑定,后面以此类推。当所有异步页面全部调用完成,页面上的绑定将变得十分混乱,各种元素绑定,渲染后的视图内容逻辑不清,又不得不声明各种变量保存每次异步加载时返回的数据,因为页面交互需要对这些数据做操作,最后写完,项目代码就成了一锅粥。 二、前端mvc   为了更方便的统一管理页面上的事件、数据和视图内容,就有了早期mvc的框架设计。mvc可以认为是一种设计模式,其基本思路是将dom交互的过程分为调用事件、获取数据、管理视图。即将之前所有的事件、数据、视图分别统一管理。用model来存放数据请求和数据操作,视图来存放对视图的操作和改变,controller用来管理各种事件绑定。   例如,SPA中的每个异步页面可以看成是一个组件,之前的做法是每个组件独立完成自己的数据请求操作、渲染和数据绑定,但是组件多了,每个组件自己去做就比较混乱,逻辑比较混乱。到了mvc里面,所有的组件数据请求、渲染、数据绑定都到一个统一的model、view、controller注册管理。后面的操作我们就不在管你有多少个组件了,你要调用必须要通过统一的model、view、controller来调。通俗来说就像是组件交出了自己控制权到一个统一的地方注册调用,这样就方便了很多,相信大家都已经了解过,这里就省篇幅不举例了。 三、 前端mvp   mvp可以跟mvp对照起来看,而且我们也很少专门去关注它。和mvc一样,mvc的M就是 Model, V就是View,而P,则代表Presenter,它与Controller有点相似。不同的是,在mvc中V会直接展现M,而在mvp中V会把所有的任务都委托给P。V和P会互相持有reference,因此可以互相调用。 例如我们可以在MVC代码上做一点改变,写成这样: 1<div controller="Controller.vp" id="text">html</div> 1 2 3 4 5 6 7 8 9 10 11 12 13var Controller = new Controller(); Controller['vp']= new VP({...


  • 【原译】自文档化的JavaScript代码的开发方法

      在我们的编程开发中,如果能在没有一行注释的代码中找到注释,是不是很意思呢?   我们经常容易犯一个错误:我们修改了一段代码,但是忘记修改更新注释。混乱的注释并不会打断你代码的执行,但是想象一下debug的时候会发生什么事情。你认真地阅读了注释,它说的是一件事,但是代码干的是另一件事。结果是,你浪费了很多时间发现注释是错误的,甚至最糟糕的是,你可能完全被误导了。   但是代码中完全不写注释也不是一个很好地选择。在我超过15年的编程经验中,我从未觉得代码库中的注释是完全没用的。   然而,有一些办法可以来帮助减少代码注释的必要性。我们可以利用某些编码技巧来让我们的代码变得更清晰,例如就是利用编程语言的特点。这样不仅能帮我们的代码变得更加清晰易理解,而且还能能帮助我们改善程序的设计。   这类代码通常被称为自文档化代码。让我来给大家展示下怎样利用这种方式编码。当然,我这里我演示的代码使用的是JavaScript语言,你们也可以利用这里大部分的技巧运用到其他的语言中。 概述   一些编程者将注释归纳到自文档化代码的范畴。在这篇文章中,我们只关注代码。注释很重要,但是却单独覆盖了太多东西。我们可以把自文档化代码归为三大类: 结构类自文档化。使用代码的结构和目录来让代码变得清晰 命名自文档化。例如函数或变量命名让代码更易理解 语句相关自文档化。我们利用语言的特性来让代码变得清晰 一、结构类自文档化   首先我们看下结构类自文档化。这里指的是通过移动部分代码来让代码变得清晰。 将代码移动到函数里面。   这和提取函数重构一样,意思是我们将已经写好的代码移动到一个新的函数里:即提取代码成为一个新函数。例如: 1var width = (value - 0.5) * 16;   不是很清晰,这里添加一个注释会很有帮助,或者,我们将它提取到一个函数里面进行自文档描述: 1 2 3 4 5var width = emToPixels(value); function emToPixels(ems) { return (ems - 0.5) * 16; }   这里唯一的变化是我们把计算放到函数里面。函数的名称描述了代码的作用,所以代码的意思就不言而喻了。另一个好处是,我们现在有一个到处可以调用的辅助函数,所以这种方法也增强了代码复用性。 用函数代替条件表达式   如果没有注释,含有多个操作运算的语句很难理解。我们可以使用一个简单的方法来描述。 1 2if(!el.offsetWidth || !el.offsetHeight) { }...


  • 【原译】webpack 2和babel 6的tree-shaking

      Rich Harris的模块打包机Rollup提出了JavaScript世界的一个新特性:Tree-Shaking,为打包文件去掉不必要的导出内容。Rollup依赖ES6模块的静态结构(讲解了imports内容和exports内容在JavaScript执行时是不变的)检测来决定哪个导出是不必要的。   webpack 2的Tree-Shaking还在beta阶段。这篇文章讲解了它是如何工作的。也可以先看个demo:tree-shaking-demo 1、webpack 2如何排除无用导出   webpack的新beta版本webpack 2通过下面两步来排除无用的导出: 首先,所有的ES6模块文件都合并成一个打包后的文件。在这个文件中,没有被import过的exports是不会被合并进来的。 其次,打包后的文件被合并minified时移除了不用的代码。所以,哪些没有被导出或没有被使用的入口就不会出现在minified压缩后的包里了。没有第一步的操作,不用的代码就不会被移除掉(而是作为一个export被注册进来)。   如果模块系统有静态结构,无用的导出将在打包的时候被检测出来。所以,webpack 2可以分析理解所有的ES6代码并且只在检测到是ES6模块时才使用tree-shaking。然而,只有import导入和export导出的模块才会被编译为ES5,如果你希望所有的打包文件都编译为ES5,你需要使用一个转译器来处理剩下来的文件。这篇文章中,我们将使用babel 6。 2、ES6 代码   样例代码含有两个ES6 模块1helpers.js 和1main.js 。 1 2 3 4 5 6 7// helpers.js export function foo() { return 'foo'; } export function bar() { return 'bar'; } 1 2 3 4 5// main.js import {foo} from...


  • 【原译】解开面条代码: 怎样书写可维护JavaScript

      [译者注]:这篇文章结合作者自己的经历确实写的很到位,大部分内容感同身受。同时作者很有条理的告诉我们应该怎样去思考解决问题。推荐给大家~   几乎每个开发者都有接手过维护遗留项目的经历,或者说是一个旧的项目想继续维护起来。通常第一反应是抛开它们代码规范基础,按自己的意思去写。这样代码会很乱,不可理解,并且别人可能要花费好几天去读懂代码。但是,如果结合正确的规划、分析、和一个好的工作流,那就有可能把一个面条式的代码仓库整理成一个整洁、有组织并易扩展的一份项目代码。   我曾经不得不接手并整理很多的项目。但还没有很多开始就很乱的。但实际上,最近就遇到了一个这样的情况。虽然我已经学会了关于JavaScript代码组织的很多知识,最重要的是,在前一个项目开发维护中几乎疯掉。在这篇文章中我想分享下一些我的步骤和我的经验。 一、分析项目   最开始的一步是看一下到底怎么回事。如果是个网站,点击网站所有的功能:打开对话框、发送表单等等。做这些的同时,打开开发者工具,看下是否报错或输出日志。如果是个nodejs项目,打开命令行接口过一下api,最好的情况是项目有一个入口(例如main.js,index.js,app.js),通过入口能将所有的模块初始化;或者最坏的情况下,也要找到每个业务逻辑的位置。   找出使用的工具。jquery?React?Express?列出需要了解一些一切重要的东西。如果所在项目使用angular2写的,而你还没有使用过,直接去看文档先有个基本的了解。总之需要找下最好的开始方案。 在更高的层次上看项目   要知道技术是一个好的开始,但是为了有一个真实的感觉和理解,是时候研究下单元测试了。单元测试是用来测试功能和代码的方法是否按预期调用的一种方式。相比阅读代码和运行代码,单元测试能更深入的帮你了解代码。如果在你的项目中还没有单元测试,别急,我们接着往下看。 二、创建一个基准   这些都是关于代码一致性的内容。现在你已经了解了项目中使用的所有工具集,你知道了代码的结构和逻辑功能的位置,是时候建立一个基准了。我建议添加一个1editorconfig 文件来保证代码在不同的编辑器、ide或不同的开发者之间的编写风格一致。 正确的缩进   这是一个饱受争议的问题(跟战争一样),代码中使用空格还是tab,其实这不重要。如果之前代码用的空格,那么使用空格,如果使用tab,继续使用。如果代码中都使用到了,那么是时候决定使用哪个了。讨论的观点是好的,但是一个好的项目目的是必须保证所有的开发者能在一起和谐的工作。   为什么这很重要。因为每个人都有使用自己编辑器或使用ide的方式。举例来说,我是code folding的追捧者。没有这些特性,我几乎在一个文件里面迷失。如果缩进不是一样的,那么代码会看起来很乱。所以,们每次我打开一个文件,在我开始工作之前必须修复缩进的问题。这很浪费时间。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20// While this is valid JavaScript, the block can't // be properly folded due to its...


  • 【原译】javascript中的错误处理

    【原译】javascript中的正确错误处理   A Guide to Proper Error Handling in JavaScript   这是关于JavaScript中异常处理的故事。如果你相信墨菲定律,那么任何事情都可能出错,不,一定会出错!这篇文章中我们来看下JavaScript中的出错处理。文章会覆盖异常处理使用的正反例,然后看下ajax的异步处理。   JavaScript的事件驱动机制让JavaScript更加丰富,浏览器好比就是一个事件驱动的机器,错误也是一种事件。当一个错误发生时,一个事件就在某个点抛出。理论上,有人会说错误是Javascript中的简单事件。如果你觉得是这样,那你就要好好去看看了。另外这篇文章只关注浏览器端的JavaScript的情况。   这篇文章将在《Exceptional Exception Handling in JavaScript》这篇文章的概念基础上进行解释。解释起来就是,当发生错误时,JavaScript会去调用栈检查异常事件。如果你对此不熟悉建议先去看看基础的东西。我们的目的是探索处理异常的必要性,接下来你会看到一个 1try...catch 块语句,你要认真思考。 例子   例子的代码在github上,而且最终展示成这样:   所有的按钮点击是都会触发”炸弹”,这个炸弹模拟了一个抛出的 1TypeError 异常。下面是这个模块单元测试的定义: 1 2 3 4function error() { var foo = {}; return foo.bar(); }   开始时,这个函数定义了一个空的对象1foo ,注意 1bar() 没有在任何地方定义,我们用一个测试用例来看下它是如何引爆炸弹的。 1 2 3it('throws a TypeError', function () { should.throws(target, TypeError);...

公众号

加我赏红包,哈哈哈

公众号

欢迎关注 极限前端 公众号