>  기사  >  CMS 튜토리얼  >  jQuery 플러그인이 사용되지 않는 14가지 가능한 설명

jQuery 플러그인이 사용되지 않는 14가지 가능한 설명

王林
王林원래의
2023-09-04 15:05:07799검색

jQuery 插件未使用的 14 种可能解释

jQuery 플러그인을 개발하는 사람이 너무 많아서 단순히 더 나은 언어가 없어서 짜증나는 상황에 직면하는 것은 드문 일이 아닙니다. 예제나 문서가 없으며 플러그인이 모범 사례를 따르지 않습니다. 하지만 당신은 운이 좋은 사람 중 하나입니다. 이 기사에서는 피해야 할 함정에 대해 자세히 설명합니다.

Nettuts+를 자주 사용하는 사람들에게 jQuery는 낯설지 않습니다. Jeffrey Way의 jQuery를 배우는 30일(및 여기와 다른 곳의 다양한 튜토리얼)은 훌륭하며 우리 모두를 Sizzle 기반 Awesomesauce로 안내합니다. 온갖 과대광고와 개발자 및 브라우저 공급업체의 JavaScript 채택이 크게 도약하는 가운데 수많은 플러그인이 등장했습니다. 이것이 jQuery가 가장 인기 있는 JavaScript 라이브러리인 이유 중 하나입니다! 유일한 문제는 그들 중 많은 수가 그다지 좋지 않다는 것입니다.

이 기사에서는 특히 JavaScript보다는 플러그인 제공 모범 사례에 더 중점을 둘 것입니다.


1 - jQuery 플러그인을 만들고 있지 않습니다

jQuery 플러그인을 생성하는 "올바른 방법"으로 어느 정도 보편적으로 받아들여지는 몇 가지 패턴이 있습니다. 이러한 규칙을 따르지 않으면 플러그인이... 형편없을 수 있습니다! 가장 일반적인 패턴 중 하나를 고려해보세요.

으아악

먼저 전역 변수 사용을 피하기 위해 자체 호출 익명 함수를 만듭니다. $windowundefined。调用自调用函数的参数是 jQuerywindow를 전달합니다. undefed에 대해 아무것도 전달하지 않으므로 플러그인에서 undefine 키워드를 사용하기로 결정하면 "undefine"은 실제로 정의되지 않습니다.

이렇게 하면 다른 스크립트가 잠재적으로 undefined 分配恶意值,例如 true를 보내는 것을 방지할 수 있습니다!

$ 作为 jQuery 传递;我们这样做是为了确保在匿名函数之外, $ 여전히 Prototype과 같은 다른 콘텐츠를 완벽하게 참조할 수 있습니다.

전역적으로 액세스 가능한 window 객체의 변수를 전달하면 축소 프로세스를 통해 더 많은 코드를 압축할 수 있습니다(이 작업도 수행해야 함).

다음으로 jQuery 플러그인 모드인 $.fn.PluginName。这是注册插件以使用 $(selector).method() 형식 방식을 사용합니다. 새로운 메소드로 jQuery의 프로토타입을 확장할 뿐입니다. jQuery 객체에 함수를 정의하는 플러그인을 생성하려면 다음과 같이 직접 추가하세요.

으아악

이 유형의 플러그인은 jQuery 객체 속성으로 정의된 함수가 일반적으로 jQuery 객체를 반환하지 않기 때문에 연결할 수 없습니다. 예를 들어 다음 코드를 고려해 보세요.

으아악

여기에서는 문자열 배열을 반환합니다. 단순히 배열로 반환하는 것이 합리적입니다. 왜냐하면 그것이 아마도 사용자가 사용하기를 원할 것이기 때문입니다(원하는 경우 jQuery 객체로 쉽게 래핑할 수 있습니다). 대신 다음과 같은 인위적인 예를 고려해보세요:

으아악

이 경우 사용자는 $.getOddEls에서 반환된 jQuery 개체를 예상할 수 있으므로 전달된 함수에 의해 정의된 jQuery 컬렉션을 반환하는 필터 메서드를 반환합니다. 경험상 좋은 규칙은 반환된 요소를 jQuery 함수로 래핑하는 것입니다. 특히 연결될 수 있는 경우 배열, 문자열, 숫자, 함수 또는 기타 데이터 유형을 반환하는 경우 해당 요소를 열어 두십시오.


2 - 코드를 (올바르게) 문서화하지 않았습니다

코드를 게시할 때 할 수 있는 가장 중요한 일은 필요한 문서를 추가하는 것입니다. 개발자에게 설명하는 내용과 코드가 실제로 수행하거나 수행할 수 있는 작업 사이의 차이는 사용자가 코드의 내용을 파악하는 데 시간을 낭비하고 싶어하지 않는다는 것입니다.

문서화는 엄격하고 빠른 규칙이 없는 관행입니다. 그러나 일반적으로 문서화가 잘 정리되어 있을수록 더 좋다는 것이 인정됩니다.

이 프로세스는 내부 실행(코드 전체에 분산되어 있음)이자 외부 실행(모든 공개 메서드, 옵션 및 여러 사용 사례가 Wiki 또는 Readme 파일에서 철저하게 설명됨)이어야 합니다.


3 - 충분한 유연성이나 사용자 정의 가능성을 제공하지 않습니다

가장 인기 있는 플러그인은 사용자가 제어하려는 변수(대부분의 플러그인에서 "옵션" 개체라고 함)에 대한 전체 액세스 권한을 제공합니다. 또한 다양한 상황에서 재사용할 수 있도록 플러그인의 다양한 구성을 제공할 수도 있습니다. 예를 들어 간단한 슬라이더 플러그인을 생각해 보겠습니다. 사용자가 제어할 수 있는 옵션에는 애니메이션의 속도, 유형 및 지연이 포함됩니다.

플러그인에 의해 삽입되거나 조작되는 DOM 요소에 추가된 클래스/ID 이름에 대한 액세스 권한을 사용자에게 제공하는 것도 좋은 생각입니다. 그러나 또한 슬라이드가 전환될 때마다 또는 슬라이드가 처음으로 다시 전환될 때(완전한 "루프") 콜백 함수에 액세스하려고 할 수도 있습니다.

귀하의 임무는 플러그인의 가능한 모든 용도와 요구 사항을 고려하는 것입니다.

또 다른 예를 생각해 보겠습니다. API를 호출하는 플러그인은 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 });

宣传这一点的另一种方式是提供“钩子”作为选项。从 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 - 당신은 테스트를 받지 않았습니다

아, 그런데 - 당신은 코드를 테스트했지요? 그렇지 않다면 코드가 예상대로 작동하는지 어떻게 확인/주장합니까? 수동 테스트가 필요하지만, 한 시간에 수없이 브라우저를 새로 고치는 경우에는 잘못하고 있는 것입니다. QUnit, Jasmine 또는 Mocha와 같은 도구를 사용해 보세요.

테스트는 GitHub에서 끌어오기 요청을 병합할 때 특히 유용합니다. 새로운/수정된 코드가 기존 플러그인을 손상시키지 않는지 확인하기 위해 모든 요청에 ​​테스트를 제공하도록 요구할 수 있습니다.

jQuery 플러그인 테스트 개념이 처음이라면 프리미엄 독점 스크린캐스트인 jQuery 플러그인을 구동하는 기술 테스트를 시청해 보세요. 또한 이번 주 후반에 웹사이트에서 Jasmine을 사용한 새로운 JavaScript 테스트 과정을 시작합니다!


유용한 자료

네가 뭘 잘못했는지 알려주는 것만으로는 아무런 호의도 베풀지 않을 거야. 다음은 올바른 길로 돌아갈 수 있는 몇 가지 링크입니다!

  • 30일 안에 jQuery를 배워보세요
  • 기본 jQuery 플러그인 패턴 - Smashing Magazine
  • 상속 패턴을 사용하여 대규모 jQuery 애플리케이션 구성
  • 플러그인 작성을 위한 공식 jQuery 문서
  • jQuery 상용구
  • OOP jQuery 플러그인 템플릿
  • 고급 jQuery 플러그인 작성을 위한 10가지 코딩 팁

결론

jQuery 플러그인을 작성하는 경우 위에 나열된 함정을 피하는 것이 중요합니다. 플러그인 성능이 좋지 않다는 주요 징후를 놓치고 있습니까?

위 내용은 jQuery 플러그인이 사용되지 않는 14가지 가능한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.