分享14个jQuery插件开发人员易犯的错误

随着越来越多的开发人员开始开发jQuery插件，所以我们随时都有可能遇到很烂的插件开发“成果”。没有在线演示，没有文档，或者插件没有遵循最佳编码实 践。但是对于阅读这篇文章的朋友来说，你很幸运，因为这里我们将介绍14个jQuery插件开发中最容易犯的错误。希望大家会觉得有帮助！

随着jQuery的广泛使用，每天都出现很多新的插件 ，但是问题在于很多插件真不怎么样。

以前我们介绍过10个帮助你创建超棒jQuery插件的小技巧，在今天这篇文章中，我们将专注于jQuery插件的最佳开发实践，希望对于大家有帮助，如果你喜欢我们的文章，请给我们留言，谢谢！

错误一：不是在开发一个jQuery插件

总的来说，这里有很多大家接受的jQuery开发的模式。 如果你没有遵从这些设计模式，你开发的插件有可能很“垃圾“。看看如下最常用的模式：

(function($, window, undefined){
$.fn.myPlugin = function(opts) {
   var defaults = {
      // 设置你的选项缺省值
   }
 
  // 使用用户的选项缺省值来扩展缺省选项
  var options = $.extend(defaults, opts || {});
 
   return this.each(function(){ // jQuery链式操作
     // 插件的相关内容
   });
})(jQuery, window);

首先呢，我们创建了一个自调用的匿名方法来将我们插件中的参数和外部全局参数隔离开。我们传递$，window，和undefined三个变量参数。这些变 量和自调用的方法将和jQuery和window一起调用。对于undefined来说没有传递任何值，因此如果我们决定在插件中使用undefined 关键字的话，其实”undefined“并没有被定义。

使用这种方法可以有效的保证外部脚本被隔离而无法给undefined变量赋值，例如，将无法赋值undefined为true。

$被作为jQuery来传递；我们使用这种方法来保证在匿名方法的外部，$仍旧可以参考为其它内容，例如，prototype。

传递变量给全局性访问的window对象能允许更多经过压缩最小化(minification)处理的代码（当然，压缩是应该做的）

下 一步，我们将使用jQuery插件的模式, $.fn.PluginName。这用来登记你的插件使得其能被应用到 $(selector).method()格式中。简单使用new来扩展jQuery的prototype。如果你想创建一个jQuery的方法的话，只 需要直接添加如下代码：

$.PluginName = function(options){
   // 扩展选项，执行插件功能
}

这种类型的插件不可以执行链式操作，因为方法在jQuery对象中定义为属性，不能返回jQuery对象，例如如下代码：

$.splitInHalf = function(stringToSplit){
   var length = stringToSplit.length;
   var stringArray = stringToSplit.split(stringToSplit[Math.floor(length/2)]);
   return stringArray;
}

这个我们返回了一个字符串数组。直接返回array比较合理，因为这有可能是用户需要的返回类型（当然如果需要的话，直接使用jQuery对象来封装也很容易）。对比以上代码，我们看看如下代码：

$.getOddEls = function(jQcollection){ //
   return jQcollection.filter(function(index){
      var i = index+1;
      return (index % 2 != 0);
   });
}

在这个例子中，我们得到奇数数值，用户可能需要jQuery对象返回$.getOddEls；因此我们返回了filter方法，这个方法通过传递的方法返回了jQuery的collection定义。一个比较好的原则是封转返回的元素到一个jQuery方法中，特别是如果用户希望它可以进行链式操作；如果你返回数组，字符串，数据，方法或者其它类型，则不需要封装。

错误二：不书写文档或者不正确的书写文档来注释你的代码

无可厚非，对于发布代码来说最重要的是书写很好的文档。这是帮助你的使用者更好的了解代码功能及其能够实现功能的而一个很好的方式。用户可不愿意花大量时间研究你的代码输入输出。

文档书写没有什么强制的规则，理论来说你给的文档越多，肯定越好。

这个过程包括了代码内部注释说明及其外部的使用API文档或者应用演示。

错误三：没有提供足够的灵活性和自定义

最受欢迎的插件提供了对于参数（即用户使用的插件选项）完整的访问。他们可以提供很多不同的配置，这样可以应用到不同的场景中。例如，我们这里看看一个简单幻灯插件。可以控制的选项包括了速度，类型和动画的延迟。

比较好的实践是提供用户访问class或者ID名称。更好的话，你可能想调用幻灯过渡后的callback方法，或者是幻灯恢复到最初的状态的callback。

你需要考虑所有插件的可能使用场景和需求。

这里我们在看看另外一个例子：一个调用API的插件应该提供对于返回对象的访问。看看如下这个例子：

$.fn.getFlickr = function(opts) {
   return this.each(function(){ // jQuery chainability
      var defaults = { // setting your default options
         cb : function(data){},
         flickrUrl : // some default value for an API call
      }
       // extend the options from defaults with user's options
       var options = $.extend(defaults, opts || {});
 
       // call the async function and then call the callback
       // passing in the api object that was returned
       $.ajax(flickrUrl, function(dataReturned){
         options.cb.call(this, dataReturned);
      });
   });
}

这个插件允许我们执行如下代码行：

$(selector).getFlickr(function(fdata){ // flickr data is in the fdata object });

另 外一个执行类似公开化的方法是提供一个”hooks"作为选项。在jQuery1.7.1及其以上版本中，我们可以在插件调用后使 用.on(eventName, function(){})方法以便分开自己独立的方法行为。例如，使用上面的插件，我们可以修改代码如下：

$.fn.getFlickr = function(opts) {
   return this.each(function(i,el){
      var $this = el;
      var defaults = { // setting your default options
         flickrUrl : "http://someurl.com" // some default value for an API call
      }
       var options = $.extend(defaults, opts || {});
 
       // call the async function and then call the callback
       // passing in the api object that was returned
       $.ajax(flickrUrl, function(dataReturned){
         // do some stuff
         $this.trigger("callback", dataReturned);
      }).error(function(){
            $this.trigger("error", dataReturned);
         });
   });
}

这样允许我们调用getFilckr插件并且链式其它行为的处理。

$(selector).getFlickr(opts).on("callback", function(data){ // do stuff }).on("error", function(){ // handle an error });

你可以看到提供这种灵活方式是绝对重要的，插件拥复杂的操作越多，那么控制就会越复杂。

错误四：要求太多的配置

上面的错误三我们介绍了越复杂的插件，要求控制就越复杂。一个很大的错误在于，插件创建了太多的选项。例如，对于UI插件来说比较理想的方式是不设置缺省的选项。

$(selector).myPlugin();

当然，有时候这不太现实（例如，插件中用户需要指定RSS Feed来源）。在这里例子中，你应该尽量为用户设置初始的选项。

例如你开发一个需要从Tweet取得内容的插件。你可以要求用户输入一个用户名，如下：

$(selector).fetchTweets("gbin1"); 

你可以提供缺省的展示方法，例如，feed个数，显示在<p>标签中。大多数的开发人员都希望是这样的。

错误五：将外部的CSS和行内的CSS混淆

如 果你处理UI的话，不可避免的需要在你的插件中包含CSS文件。一般来说，这是一个可接受的解决方式。多数的插件都带有图片和CSS。但是不要忘了错误 二，文档需要包含如何使用这些CSS和图片的内容。开发人员可没有时间来搜索你的代码来找到答案（况且，很多人可能并不会真正开发jQuery代码，特别 是在国内）。

无论如何，我们都需要保证插件能正常工作。

对于插件来说，最好的方式是使用基于Class/ID的CSS样式或者行内注入CSS（使用插件选项）。行内CSS会覆盖外部CSS，但是混合使用俩者会非常不舒服。开发人员可能会花一定时间来搞清楚为什么代码中的样式不好使。所以最好你自己决策如何处理这些问题。

作为一个规则来说，行内的CSS非常不好 - 除非它影响非常小，不会干扰外部的CSS样式定义。

错误六：没有提供任何在线演示

这绝对是很恶心的一件事，开发人员必须自己动手才能看到效果，往往发现不是自己期望的那样。其实作为插件开发来说，添加一些在线演示还是很简单的，如下是一些不错的演示模板：

A good template for examples:

• A “hello world” example – usually the plugin call with the minimum configuration/options passed, and it’s accompanying html/css
• A few more involved examples – usually with examples of full functionality of multiple options
• An integration example – if someone might use another plugin with your plugin, here is where you can show how to do that. (This gets you bonus points in the open-source development world, too. Kudos.)

错误七：代码没有匹配正确的jQuery版本

jQuery 和其它的代码类库类似，也有不同的版本。大多数的方法即使被遗弃也会被保留。但是新的方法会被添加。一个非常典型的例子是.on方法。它是jQuery新 版本中事件处理的一个全新的all-in-one解决方案。如果你书写使用到.on()方法的插件的话，需要使用到jQuery1.6或者以上版本。

一 个比较好的习惯是在你的文档中说明，你要求的jQuery版本，例如，1.7或者以上，作为我个人来说，在使用jQuery插件中也有类似不愉快的体验。 所以为了让更多的开发人员喜欢你的插件，一定要很好的说明。并且提供一个不再支持的旧版本下载也是一个相当不错的方法。

问题。

鼓励大家使用新的jQuery类库，但是不要让你的插件失效的太频繁了！提供一个不再支持的旧版本下载也是一个相当不错的选择。

错误八：找不到修正说明

除了保证你的jQuery版本的支持和兼容性，你还需要版本控制（例如，Github）。 如果你希望你开发的jQuery插件最后能够公开发布的话，你最好保存在Github中。使用版本控制有诸多的好处，具体就不在这篇文章中详细说明。但是 最重要的在于允许使用你的插件的开发人员看到相关的修改，提升或者兼容性的bug修正。这同时能够帮助你扩展/提高你的插件的用户体验。

更多资源：

• The Git Book
  
• The Perfect Workflow With Git, GitHub, and SSH
  
• Getting Good With Git ($19)
  
• GitCasts
  

错误九：开发的插件并没有人使用

这里我们得提一下，很多插件都很简单，或者说是肤浅，没有任何理由来称之为插件。这个世界不再需要幻灯插件了！

我们不需要闭门造车，很多已经存在的不错的插件，为什么还需要再去开发呢？

这个世界不再需要幻灯插件了。

错误十：没有提供一个压缩最小化版本

这个问题非常简单明显，如果是一个可供使用的插件，意味着是ready to use的代码，试问如何在产品环境中使用一个超大的js代码呢？

请参考错误十三来寻找自动处理解决方案。

错误十一：把代码写的太“聪明”

当你书写一个插件的时候，你是不是打算给别人使用的呢？如果你书写的代码晦涩难懂，大家如何能够debug？

如果你给变量起名gbin1，x，y，z，你绝对犯了一个大错。

错误十二：不需要使用jQuery

我 们都很喜欢使用jQuery，但是要知道它是一个类库，肯定会有些性能代价的。一般来说，你不会太在意jQuery选择器的性能。当然jQuery是被很 好的优化过的。 但是如果你只需要一些简单的DOM查询的话，你可能可以考虑使用别的技术，例如，vanilla，Zepto。

不要为了jQuery而使用jQuery，如果你使用其它技术例如，vanilla javascript，你需要注意兼容性，你有可能需要书写一些polyfill来适应新API。

错误十三：没有自动化整个过程

Grunt是一个基于任务的javascript命令行编译工具。如果有兴趣可以看看这篇文章。

grunt init:jquery

运行这个命令，将会提示你一系列问题，例如，title，描述，版本，git repository，许可等。

Grunt功能不止于此。它可以帮助你自定义boilerplate代码，并且内建很多工具，例如，JSHint ，Qunit 还有 PhantomJS

定期使用Grunt做编译工作。

错误十四：没有做过测试

你是不是认真测试过你的代码？那你怎么保证代码正常工作？只靠刷新浏览器吗？还是考虑使用一些工具吧： QUnit, Jasmine, 或者 Mocha

如果测试jQuery插件对你来说比较新的话，可以考虑多留意一些测试工具和方法。

一些有用的资源

• 30 Days To Learn jQuery
  
• Essential jQuery Plugin Patterns – Smashing Magazine
  
• Using Inheritance Patterns to Organize Large jQuery Applications
  
• Official jQuery Documentation for Plugin Authoring
  
• jQuery Boilerplate
  
• OOP jQuery Plugin Boilerplate
  
• 10 Coding Tips to Write Superior jQuery Plugins
  

希望大家喜欢我们带来的这篇文章，如果你有任何问题和意见，请给我们留言，谢谢！

via tutsplus

来源： 分享14个jQuery插件开发人员易犯的错误