событие запускается против обратного вызова в настройках - PullRequest
3 голосов
/ 22 января 2012

В плагинах jQuery, как, по вашему мнению, лучше всего разрешить перехват функции в вашем плагине - через триггеры или опции (аргументы), передаваемые в функцию плагина?

$.trigger('myplugin_completed', someData);

$(document).bind('myplugin_completed', function(event, someData){ ... });

против

myPluginOptions.onComplete(someData);

$('.stuff').myPlugin({onComplete: function(someData){ ... }});

Ответы [ 3 ]

2 голосов
/ 22 января 2012

Решение

Я думаю, что лучшее решение - по крайней мере, в случае, который вы описали (возможно, не во всех возможных случаях), - объединить оба варианта следующим образом:

$('.stuff').myPlugin(/* some options here */);
$('.stuff').trigger('myplugin.completed', someData);

и эта строка:

$('.stuff').on('myplugin.completed', function(event, someData){
    /* callback code */
});

отвечает за привязку обработчика событий. Он также может вызываться, когда кто-то передает onComplete обратный вызов в опциях при инициализации вашего плагина (конечно, селектор должен быть настроен так, чтобы он соответствовал тому, который используется кодом, инициализирующим ваш плагин).

Резюме

Подводя итог, вы могли бы:

  • создать собственное событие (completed),
  • использовать пространство имен вашего плагина для этого события / плагина (в данном случае myplugin),
  • использовать функцию .on() (доступно и предпочтительнее начиная с jQuery 1.7),
  • если опция onComplete передана вашему плагину, нет проблем с ее связыванием в коде, инициализирующем плагин (то есть изнутри плагина, используя функцию .on(), связывающую обработчик событий с именем вашего события в вашем плагине четное пространство имен).
2 голосов
/ 22 января 2012

Я буду голосовать за второй вариант , потому что таким образом можно управлять событием onComplete, и оно привязано только к элементу. Привязывать его к документам нехорошо, потому что можно делать $ (document) .unbind (), который отменяет привязку всех событий.

1 голос
/ 22 января 2012

Я думаю, что оба способа хороши, и ни один из них не имеет большого преимущества перед другим.

Например, пользовательский интерфейс jQuery использует обратный вызов для параметров и триггеры событий для фактических событий, таких как перетаскивание при запуске / остановке.

Но, создавая триггеры событий в коде, вы можете создать более гибкий способ добавления большего числа обработчиков событий без изменения существующего кода. Я имею в виду, когда вы получили обратные вызовы, это происходит следующим образом:

{onComplete: function(someData){ action_1; }}

Если вам нужны дополнительные действия, вы записываете их в функцию existion или помещаете функции внутрь:

{onComplete: function(){  action_1; action_2 }}

или

{onComplete: function(){  action_1; function_2(); }}

function_2(){ action_2 };

Для сравнения с использованием событий это будет выглядеть так:

$('selector').on('myplugin_completed.myplugin', function_1 })

Дополнительные действия:

$('selector').on('myplugin_completed.myplugin_extra', function_2 })

Если вам не нужны какие-либо действия, вы можете отменить привязку только к ним.

$('selector').off('myplugin_completed.myplugin_extra');

Между ними есть различия, но обычно это зависит от конкретной ситуации, какая из них лучше;

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...