14 explications possibles pour lesquelles votre plugin jQuery n'est pas utilisé

Avec autant de personnes développant des plugins jQuery, il n'est pas rare de rencontrer une situation où l'on est tout simplement - faute d'un meilleur langage - nul. Il n'y a pas d'exemples ni de documentation, le plugin ne suit pas les meilleures pratiques, etc. Mais vous faites partie des chanceux : cet article détaille les pièges à éviter.

Pour ceux qui utilisent fréquemment Nettuts+, jQuery n'est pas étranger. Les 30 jours pour apprendre jQuery de Jeffrey Way (et divers autres tutoriels ici et ailleurs) sont excellents et nous conduisent tous sur la voie d'Awesomesauce propulsé par Sizzle. Au milieu de tout ce battage médiatique (et du pas de géant dans l'adoption de JavaScript par les développeurs et les fournisseurs de navigateurs), une multitude de plugins ont vu le jour. C'est en partie la raison pour laquelle jQuery est la bibliothèque JavaScript la plus populaire ! Le seul problème est que beaucoup d’entre eux ne sont pas très bons.

Dans cet article, nous nous concentrerons moins sur JavaScript en particulier et davantage sur les meilleures pratiques en matière de livraison de plugins.

---

1 - Vous ne créez pas de plugin jQuery

Il existe quelques modèles qui sont plus ou moins universellement acceptés comme la « bonne façon » de créer des plugins jQuery. Si vous ne suivez pas ces conventions, votre plugin pourrait... être nul ! Considérez l'un des modèles les plus courants :

(function($, window, undefined){
$.fn.myPlugin = function(opts) {
	var defaults = {
		// setting your default values for options
	}

  // extend the options from defaults with user's options
  var options = $.extend(defaults, opts || {});

	return this.each(function(){ // jQuery chainability
	  // do plugin stuff
	});
})(jQuery, window);

Tout d'abord, nous créons une fonction anonyme auto-appelante pour éviter d'utiliser des variables globales. Nous transmettons $、window 和 undefined。调用自调用函数的参数是 jQuery 和 window ; nous ne transmettons rien pour undéfini , donc si nous décidons d'utiliser le mot-clé undéfini dans notre plugin, "undéfini" sera en fait undéfini.

Cela empêche d'autres scripts d'envoyer potentiellement undefined 分配恶意值，例如 true !

$ 作为 jQuery 传递；我们这样做是为了确保在匿名函数之外， $ Toujours pleinement capable de référencer d'autres contenus, comme Prototype.

La transmission de variables d'objets window accessibles globalement permet de compresser davantage de code via le processus de minification (ce que vous devriez également faire).

Ensuite, nous utilisons le mode plug-in jQuery, $.fn.PluginName。这是注册插件以使用 $(selector).method() méthode de formatage. Il étend simplement le prototype de jQuery avec vos nouvelles méthodes. Si vous souhaitez créer un plugin qui définit une fonction sur un objet jQuery, ajoutez-le directement comme ceci :

$.PluginName = function(options){
	// extend options, do plugin stuff
}

Ce type de plugin ne peut pas être lié car les fonctions définies comme propriétés d'objet jQuery ne renvoient généralement pas d'objets jQuery. Par exemple, considérons le code suivant :

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

Ici, nous renvoyons un tableau de chaînes. Il est logique de simplement le renvoyer sous forme de tableau, car c'est probablement ce que l'utilisateur voudra utiliser (et il peut facilement l'envelopper dans un objet jQuery s'il le souhaite). Considérons plutôt l'exemple artificiel suivant :

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

Dans ce cas, l'utilisateur peut s'attendre à ce qu'un objet jQuery soit renvoyé par $.getOddEls, nous renvoyons donc la méthode filter, qui renvoie la collection jQuery définie par la fonction passée. Une bonne règle générale consiste à envelopper les éléments renvoyés dans des fonctions jQuery, surtout s'ils peuvent être chaînés ; si vous renvoyez des tableaux, des chaînes, des nombres, des fonctions ou d'autres types de données, laissez-les ouverts.

---

2 - Vous n'avez pas (correctement) documenté votre code

La chose la plus importante que vous puissiez faire lors de la publication de code est sans doute d'ajouter la documentation nécessaire. L'écart entre ce que vous expliquez aux développeurs et ce que le code fait ou peut réellement faire est que les utilisateurs ne veulent pas perdre de temps à comprendre les tenants et les aboutissants du code.

La documentation est une pratique sans règles strictes ; cependant, il est généralement admis que plus vous avez de documentation (bien organisée), mieux c'est.

Ce processus doit être à la fois une pratique interne (dans/dispersée dans tout le code) et une pratique externe (chaque méthode publique, option et plusieurs cas d'utilisation expliqués en détail dans un wiki ou un fichier readme).

---

3 - Vous n'offrez pas suffisamment de flexibilité ou de personnalisation

Les plugins les plus populaires offrent un accès complet aux variables que l'utilisateur peut vouloir contrôler (appelées objets « options » dans la plupart des plugins). Ils peuvent également fournir de nombreuses configurations différentes du plugin afin qu'il puisse être réutilisé dans de nombreux contextes différents. Par exemple, considérons un simple plugin de curseur. Les options que l'utilisateur peut souhaiter contrôler incluent la vitesse, le type et le délai de l'animation.

C'est une bonne idée de donner également aux utilisateurs accès aux noms de classe/ID ajoutés aux éléments DOM insérés ou manipulés par le plugin. Mais en plus, ils voudront peut-être accéder à la fonction de rappel à chaque transition de diapositive, ou lorsque la diapositive revient au début (une « boucle » complète).

Votre travail consiste à considérer toutes les utilisations et tous les besoins possibles de votre plugin.

Prenons un autre exemple : un plugin appelant une API doit donner accès à l'objet de retour de l'API. Prenons comme exemple le concept de plugin simple suivant :

$.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 });

宣传这一点的另一种方式是提供“钩子”作为选项。从 jQuery 1.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);
			});
	});
}

这允许我们调用 getFlickr 插件并链接其他行为处理程序。

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

您可以看到提供这种灵活性绝对重要；您的插件的操作越复杂，可用的控件就越复杂。

---

4 - 您需要太多配置

好的，第三条建议是，您的插件的操作越复杂，可用的控制就越复杂。可用。然而，一个很大的错误是为插件功能提供了太多的选项。例如，基于 UI 的插件最好具有无参数默认行为。

$(selector).myPlugin();

当然，有时这是不现实的（例如，用户可能正在获取特定的提要）。在这种情况下，您应该为他们做一些繁重的工作。有多种方式将选项传递给插件。例如，假设我们有一个简单的推文获取器插件。该推文获取器应该有一个默认行为，带有一个必需选项（您要从中获取的用户名）。

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

例如，默认情况下可能会抓取一条推文，将其包装在段落标记中，然后使用该 html 填充选择器元素。这是大多数开发人员所期望和欣赏的行为。细粒度选项应该就是：选项。

---

5 - 您正在混合外部 CSS 规则和内联 CSS 规则

当然，根据插件的类型，如果高度基于 UI 操作，则必须包含 CSS 文件，这是不可避免的。一般来说，这是一个可以接受的问题解决方案；大多数插件都与图像和 CSS 捆绑在一起。但不要忘记第二点 - 文档还应包括如何使用/引用样式表和图像。开发人员不想浪费时间查看源代码来弄清楚这些事情。

事情应该只是......工作。

话虽如此，使用注入样式（可以通过插件选项高度访问）或基于类/ID 的样式绝对是最佳实践。这些 ID 和类也应该可以通过前面提到的选项进行访问。然而，内联样式会覆盖外部 CSS 规则；不鼓励将两者混合使用，因为开发人员可能需要很长时间才能弄清楚为什么插件创建的元素不遵守他们的 CSS 规则。在这些情况下请运用您的最佳判断。

根据经验，内联 CSS 很糟糕 - 除非它很小到无法保证有自己的外部样式表。

---

6 - 你没有提供示例

证据就在布丁中：如果您无法提供一个实际示例来说明您的插件如何使用随附的代码，人们很快就会放弃使用您的插件。就那么简单。不要偷懒。

一个很好的示例模板：

• “hello world”示例 - 通常是传递最小配置/选项的插件调用，并且附带 html/css
• 一些更复杂的示例 - 通常包含多个选项的完整功能的示例
• 集成示例 - 如果有人可能将另一个插件与您的插件一起使用，您可以在此处展示如何执行此操作。 （这也能让你在开源开发领域获得加分。值得赞扬。）

---

7 - 你的代码与他们的 jQuery 版本不匹配

jQuery，像任何优秀的代码库一样，随着每个版本的发布而成长。即使在弃用支持后，大多数方法仍会保留。然而，添加了新的方法；一个完美的例子是 .on() 方法，它是 jQuery 的新的事件委托一体化解决方案。如果您编写一个使用 .on() 的插件，那么使用 jQuery 1.6 或更早版本的人将不走运。现在，我并不是建议您针对最低公分母进行编码，但是，在您的文档中，请务必解释您的插件支持哪个版本的 jQuery。如果您引入了支持 jQuery 1.7 的插件，那么即使 1.8 发布，您也应该强烈考虑维持对 1.7 的支持。您还应该考虑利用 jQuery 中新的/更好的/更快的功能。

鼓励开发人员升级，但不要太频繁地破坏您的插件！一种选择是提供插件的“旧版”、已弃用、不受支持的版本。

---

8 - 变更日志在哪里？

如果您还没有学会如何使用版本控制，那么是时候咬紧牙关了。

除了将 jQuery 版本支持/兼容性作为文档的一部分之外，您还应该进行版本控制。版本控制（具体来说，通过 GitHub）在很大程度上是社交编码的发源地。如果您正在开发一个 jQuery 插件并希望最终发布到官方存储库中，那么无论如何它都必须存储在 GitHub 存储库中；如果您还没有学会如何使用版本控制，那么是时候硬着头皮了。版本控制有无数的好处，所有这些都超出了本文的范围。但核心好处之一是，它允许人们查看您所做的更改、改进和兼容性修复以及您何时进行这些更改、改进和兼容性修复。这也为您编写的插件的贡献和定制/扩展打开了大门。

其他资源

• Git 书
• 使用 Git 轻松进行版本控制
• 使用 Git、GitHub 和 SSH 的完美工作流程
• 熟练使用 Git (19 美元)
• GitCast

---

9 - 没有人需要你的插件

世界不需要另一个滑块插件。

好吧，我们在这里忽略它已经足够长的时间了：一些“插件”是无用的或太浅，不足以保证被称为插件。世界不需要另一个滑块插件！然而，应该指出的是，内部团队可能会开发自己的插件供自己使用，这是完全可以的。但是，如果您希望将您的插件推向社交编码领域，请找到编写更多代码的理由。俗话说，没有理由重新发明轮子。相反，接过别人的方向盘，建造一辆赛车。当然，有时会有新的、更好的方法来做已经做过的同样的事情。例如，如果您使用更快或新技术，您很可能会编写一个新的滑块插件。

---

10 - 您没有提供缩小版本

这个相当简单：提供代码的缩小版本。这使得它更小、更快。它还确保您的 Javascript 在编译时不会出现错误。当您缩小代码时，不要忘记也提供未压缩的版本，以便您的同行可以查看底层代码。对于各种经验水平的前端开发人员来说，都有免费且廉价的工具。

有关自动化解决方案，请参阅提示十三。

---

11 - 你的代码太聪明了

当你编写一个插件时，它的目的就是供其他人使用，对吗？因此，最有效的源代码是具有高度可读性的。如果您正在编写无数巧妙的单行 lambda 样式函数，或者您的变量名称没有语义，那么当错误不可避免地发生时，将很难对其进行调试。不要编写短变量名来节省空间，而是遵循技巧九（缩小！）中的建议。这是优秀文档的另一部分；优秀的开发人员应该能够检查您的代码并了解其用途，而无需花费太多精力。

如果您发现自己调用变量“a”或“x”，那么您就做错了。

此外，如果您发现自己查阅文档来记住您自己的看起来奇怪的代码正在做什么，那么您也可能需要不那么简洁并更具解释性。将每个函数的行数限制为尽可能少；如果它们延伸三十行或更多行，则可能会有代码味道。

---

11.你不需要 jQuery

​​>

尽管我们都喜欢使用 jQuery，但重要的是要了解它是一个库，而且成本很小。一般来说，您不需要太担心 jQuery 选择器性能之类的事情。不要令人讨厌，你会没事的。 jQuery 是高度优化的。也就是说，如果您需要 jQuery（或插件）的唯一原因是在 DOM 上执行一些查询，您可能会考虑完全删除抽象，而坚持使用普通 JavaScript 或 Zepto。

注意：如果您决定坚持使用普通 JavaScript，请确保您使用的是跨浏览器的方法。对于较新的 API，您可能需要一个小型的 polyfill。

---

13 - 您没有自动化该过程

使用咕噜声。期间。

Grunt 是一个“用于 JavaScript 项目的基于任务的命令行构建工具”，最近在 Nettuts+ 上对此进行了详细介绍。它允许你做这样的事情：

grunt init:jquery

此行（在命令行中执行）将提示您一系列问题，例如标题、描述、版本、git 存储库、许可证等。这些信息有助于自动化设置文档、许可等的过程。

Grunt 所做的不仅仅是为您制作一些定制的样板代码；它还提供内置工具，例如代码 linter JSHint，只要您安装了 PhantomJS（由 Grunt 负责），它就可以为您自动执行 QUnit 测试。这样，您可以简化工作流程，因为测试在保存时会立即在终端中运行。

---

14 - Vous n'êtes pas testé

Oh, au fait, vous avez testé votre code, n'est-ce pas ? Si ce n'est pas le cas, comment pouvez-vous garantir/affirmer que votre code fonctionne comme prévu ? Les tests manuels ont leur place, mais si vous actualisez votre navigateur un nombre incalculable de fois par heure, vous vous trompez. Pensez à utiliser des outils comme QUnit, Jasmine ou encore Mocha.

Les tests sont particulièrement utiles lors de la fusion de demandes d'extraction sur GitHub. Vous pouvez exiger que toutes les demandes fournissent des tests pour garantir que le code nouveau/modifié ne casse pas vos plugins existants.

Si le concept de test des plug-ins jQuery est nouveau pour vous, envisagez de regarder notre screencast exclusif à Premium, Test de la technologie qui pilote les plug-ins jQuery. De plus, nous lançons un nouveau cours Tests JavaScript avec Jasmine sur le site Web plus tard cette semaine !

---

Quelques ressources utiles

Nous ne vous rendrons pas service simplement en vous disant ce que vous avez fait de mal. Voici quelques liens pour vous remettre sur le bon chemin !

• Apprenez jQuery en 30 jours
• Modèle de plug-in jQuery de base - Smashing Magazine
• Organisez de grandes applications jQuery à l'aide du modèle d'héritage
• Documentation officielle jQuery pour la création de plugins
• JQuery passe-partout
• Modèle de plugin OOP jQuery
• 10 Conseils de codage pour écrire des plugins jQuery avancés

---

Conclusion

Si vous écrivez un plugin jQuery, il est crucial d'éviter les pièges répertoriés ci-dessus. Est-ce qu'il me manque des signes clés indiquant que le plugin fonctionne mal ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!