Лично я предлагаю придерживаться того, что команда jQuery рекомендует , с точки зрения шаблонов проектирования плагинов. Это помогает поддерживать согласованность и делает ваш плагин более дружелюбным к сообществу.
Сказав это ...
Я столкнулся с проблемой попытки сохранить состояние нескольких элементов . Одно решение, которое я нашел, состоит в том, чтобы использовать jQuery Data API (который выглядит следующим образом: $( selector ).data( key, value )) для хранения метаинформации как состояния элемента или состояния приложения.
Хорошая особенность использования data () заключается в том, что он не обновляет / не обрабатывает DOM, а использует внутренние метаданные jQuery, поэтому он быстрее доступен, чем попытка сохранить скрытые поля ввода информации, изменить имена классов или выполнить другие действия. Приколы, которые разработчики пытались использовать для хранения данных на стороне клиента. (Имейте также в виду, что вам не нужно использовать тип документа HTML5 для использования API данных, но если вы сделаете data- *, то ключевые атрибуты будут чрезвычайно полезны !)
Это сложно, когда все элементы имеют свои собственные состояния, но элемент current контролирует общее состояние плагина. Для этого сценария я использую тег body для хранения данных о текущем элементе , примерно так:
$('body').data('myPluginNameSpace.current', selectorRef );
Таким образом, когда мне нужно проверить состояние моего плагина / страницы / приложения или прослушать событие, специфичное для плагина, которое всплывает до объекта документа, я могу быстро найти текущий / выбранный элемент, и применить к нему любые изменения или поведение пользовательского интерфейса:
var currentElementRef = $('body').data('myPluginNameSpace.current');
doFunStuff( currElementRef );
Существует также ряд других способов сделать это, например, создание пользовательского объекта Event и присоединение к нему пользовательских параметров :
var myPluginEvent = jQuery.Event( 'customEvent.myPluginNameSpace', { myProp : myValue });
$( document ).trigger( myPluginEvent );
Когда ваше пользовательское событие запускается и позже обрабатывается с помощью функции обратного вызова, ваши пользовательские параметры присоединяются к объекту события, передаваемому обработчику:
$( document ).on( 'customEvent.myPluginNameSpace', function( e ){
doStuff( e.myProp ); //you can access your custom properties attach to the event
});
Вы можете добраться до одного и того же пункта назначения по разным дорогам; это красота и ужас JavaScript.
В вашем конкретном случае имейте в виду, что вам не нужно, чтобы все работало внутри return this.each({ }) части функции method.init для вашего плагина:
Например, если вы не устанавливаете конкретные параметры для каждого элемента, я бы выбрал ту часть, где вы расширяете объект параметров для каждого элемента!
var methods = {
init: function(options) {
//DO OPTIONS/EVENTLISTENER/etc STUFF OUT HERE
return this.each(function() {
//DONT DO THIS
if (options) {
_options = $.extend($.fn.examplePlugin.defaults, options);
} else {
_options = $.fn.examplePlugin.defaults;
}
Попробуйте вместо этого:
...
var methods = {
init : function( options ){
//do setup type stuff for the entire Plugin out here
var _options = $.MyPlugin.options = $.extend( defaults, options );
//add some listeners to $(document) that will later be handled
//but put them in an external function to keep things organized:
//methods.addListeners()
//this refers to the array of elements returned by $(selector).myPlugin();
//this.each() iterates over, EACH element, and does everything inside (similar to Array.map())
//if the selector has 100 elements youre gonna do whats in here 100 times
return this.each(function(){
//do function calls for individual elements here
});
},
Кроме того, использование пользовательских событий поможет вам! Добавьте некоторые прослушиватели событий к объекту документа и дайте обработчикам событий выяснить, с каким элементом следует взаимодействовать, используя API данных или пользовательские параметры событий.