Правила хорошего тона при написании плагина на jQuery

[@mrsum]

Хороший туториал, но содержание устарело. Лет на 5.

[@Akuma]

jQuery сейчас… не в моде, чтоли. Посмотрите на ваши же проекты, скорее всего вы используете его только для навешивания событий, show/hide и ajax запросов. В 99% обычных проектов большего и не нужно. Даже анимации, которыми раньше пользовались все, сейчас делают на CSS.

Плагины для jQuery тоже устарели. Но если уж пишите туториал по ним, то к «шаблону» добавьте поддержку AMD/CommonJs (или лучше обоих сразу), чтобы при подключении плагинов, например webpack-ом, не приходилось что-то дописывать.

[@Akuma]

Я ж и не спорю. как раз объясняю, что время jQuery постепенно уходит.

[@RUQ]

Жаль его нет в IE, можно конечно использовать полифил, но это опять значит какой-то доп.инструмент.

[@skoder]

Спасибо, обновил статью про bower и npm.

По поводу jQuery вы безусловно правы, его все меньше и меньше, но когда мне к примеру требуется навешать на элемент события или несколько событий. Я без раздумий пишу.

$('#elm').on('click keydown mousedown', someHandler) 

Все то же самое я могу сделать и на vanila.js, но мне как минимум нужно будет описать, что-то вроде

function on(elm, events, handler) {
   if (elm) {
       events.split(' ').forEach(function (event) {
           elm.addEventListener(event, handler);
       });
   }
}

А это уже лишний не нужный код. Безусловно уже есть множество удобный библиотек для этих целей, но зачем использовать их все, если есть одна

[@Akuma]

Да я и сам им пользуюсь, уже скорей по привычке, да и у пользователей он скорее всего закеширован. Хотя для мобильников когда что-то делаю, стараюсь вообще отказываться от библиотек/фреймворков по возможности.

[@dshster]

Избавляясь от 3 строчек «лишнего» кода вы тянете целую библиотеку и ставите свой скрипт в зависимость от неё. Потом другой разработчик на каком-нибудь, например, Ангуляр, захочет использовать ваш плагин и ему придётся тянуть лишнюю зависимость, которая в самом Ангуляре ни к чему. Так и получается, что веб пухнет от всех зависимостей, потому что авторы считают нативные реализации «лишним кодом».
В вашем коде нет ничего, чего нельзя или очень затратно сделать не используя jQuery.

[@vshemarov]

Хм, написал автор плагин с использованием jQuery, а потом "другой разработчик на каком-нибудь, например, Ангуляр, захочет использовать ваш плагин и ему придётся тянуть лишнюю зависимость"…

Если я пишу с использованием jQuery, то и готовые решения подбираю на jQuery, если пишу на Angular, то и решения подбираю соответствующие. А если я начинаю ради пары-тройки плагинов тянуть в один проект несколько фреймворков и больших библиотек — это однозначно проблема во мне, а не в тех, кто писал хорошие плагины под конкретные фреймворки

[@rznELVIS]

+1. Всему свое место. Вообще Ангуляр просто так не вводится, т.е. если вы уж решили вводить ангуляр то стройте под него приложение, а не цепляйте на ходу, а используйте jquery

[@dshster]

А что заставляет разработчиков плагинов под Ангуляр использовать jQuery? Может, как автор выше прокомментировал: «без раздумий» подключать jQuery везде?

[@dshster]

Вы попробуйте на ng-modules поискать UI плагины под Ангуляр — большая часть из них зависит от Bootstrap и от jQuery.
Я конечно понимаю, что выбор разработчика под какие библиотеки и фреймворки выбирать плагины, но ведь ничто не мешает разрабатывать компоненты без зависимостей и использовать их с любым фреймворком? Современные браузеры уже давно решили проблему работы с DOM.

[@boodda]

Тут как бы и зарыта проблема, что вот никак не получится в нормальном проекте без НЕ современных браузеров. Пишу полгода уже новую версию проекта(сервис), с нуля. И вот казалось бы сейчас развернусь, а тут говорят что у IE8 есть достаточная доля рынка и мы не можем его игнорировать. И все классные разработки идут лесом

[@Mithgol]

Насчёт npm подскажу, что можно немного упростить себе жизнь, если из корня проекта вместо команды «npm publish ./» (которую Вы порекомендовали) подавать команду «npm publish» без дополнительных уточнений. (Эта команда по умолчанию работает с текущим каталогом, поэтому его явное указание в виде «./» — это лишнее.)

[@skoder]

Спасибо, дополнил статью про автоматизацию этого процесса.

[@gvozd1989]

А что в моде?

[@Fen1kz]

(Дисклеймер: это ответ на вопрос "что в моде", а не холивар "х лучше jQuery")

Angular (уже выходит из моды), React (подходит к закату). Angular 2 и его конкуренты.

[@Akuma]

Ну на счет реакта я бы поспорил, а ангуляр просто обновится до второй версии. Да и ни то ни другое заменой JQ не является: фреймворк библиотеке не замена.

По «что в моде» — ES6-7 и современные браузеры. Ведь изначально jQuery создавалось именно что-бы избавить программистов от плясок вокруг кучи браузеров.

[@Sirion]

Я бы сказал, ES6-7 и транспайлеры.

[@dshster]

Ангуляр1 и Ангуляр2 абсолютно разные фреймворки, это не обновление и даже не расширение. Возможно Ангуляр2 следовало бы назвать другим именем, но видимо хотелось использовать прежний бренд для узнаваемости.

В Ангуляре2 есть проблема (на мой взгляд проблема), то, что он под 3 платформы сразу — JavaScript, TypeScript и Dart. Я не знаю как комьюнити приспособится к такому делению.

> Ведь изначально jQuery создавалось именно что-бы избавить программистов от плясок вокруг кучи браузеров

Всё верно, но технологии не стоят на месте — если что-то было удобно во времена IE6(7), то это не значит, что нужно тянуть технологию до IE12 (Edge, условно).

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

[@Zetoke]

А какое основание насчёт того, что React "подходит к закату".

[@rznELVIS]

какая разница что в моде. Главное что эффективно

[@Akuma]

Это ИТ. Здесь то, что не эффективно — не в моде. И наоборот.

[@AlexPTS]

Для своих классов можно использовать паттерн модуля и паттерн открытия модуля, когда функция конструктор возвращает явно объект. Который является по сути маппингом на методы и свойства замыкания, чтобы сделать из публичными.

[@RubaXa]

Ещё хороший тон, когда плагин поддерживает привычные интерфейс jQuery UI, а это:

$('.js-target').plugin('widget'); // возвращает ссылку на инстанс
$('.js-target').plugin('option', 'name'); // получить опцию
$('.js-target').plugin('option', 'name', 'value'); // установить
$('.js-target').plugin('destroy'); // уничтожает всё связанное

Если плагин порождает какой либо html, нужно оформлять его в виде шаблона, хотя бы с простецкой заменой по регулярке /\{(.*?)\}/ или тот же MicroTemplate использовать, там пара строчек. А совсем хорошо, когда можно передать функцию, чтобы в зависимости от параметра вернуть нужны html. Тоже самое касается всех имен классов и селекторов, которые используют плагин. Всё должно быть конфигурируемо.

Так же нужно корректно использовать data:

// Плохо
$(this).data('tooltips');

// Плохо
var NAMESPACE = 'tooltips';
$(this).data(NAMESPACE);

// Нормуль
var NAMESPACE = 'tooltips:' + Math.random();
$(this).data(NAMESPACE, instance);

Ещё одно правило хорошего тона, которое в целом относиться к любой публичной разработке, это выносить все внутренние утилитные методы, если они не приватные, в публичный статик объект, например какой-нибудь utils. Очень часто бывает, что уже все нужные методы для работы, те же самые: extend, addEvent, each и тому подобное, уже есть, но они оставлены в замыкании из-за чего приходится писать ровно тот же код, неуклонно увеличивая энтропию Вселенной.

[@skoder]

Я так понимаю, чтобы никто случайно не затер эти данные.

[@RubaXa]

Чтобы ваш плагин не пересекся с другими пользовательскими данными или другим плагином.

[@Igogo2012]

Могу конечно ошибаться но конструкция

var self = this;

вроде бы считается антипаттерном, так как давно существует .bind(this) в прототипе Function

[@RubaXa]

bind — полифилить нужно.
А вот self, that, t и т.п. хорошо бы заменить на четкое и понятное _this.

[@mrsum]

bind не надо полифилить? Вот это поворот :)

[@RubaXa]

Добро пожаловать в реальный мир, где есть такие браузеры как IE < 9 и PhantomJS.

[@mrsum]

А простите, почему-то подумал как раз о том, что не нужно полифилить )
Вы конечно правы, мое беглое чтение Вашего коммента привело к непониманию.

[@RubaXa]

Ага, как мое вашего, так что норм.

[@YNile]

Сравнивать не совсем корректно :)
Это разный подход.

self — создает замыкание.
.bind(this) — возвращает новую функцию.