Как стать автором
Обновить

Комментарии 50

В последствии чего задав новое значение переменной все привязанные теги на странице обновятся.
Если я правильно понял, все привязанные теги на странице сначала зададут новое значение переменной в каком-то последствии (не указано, последствии чего), а потом обновятся?
Не зададут. При привязке тегов, значения тегов остаются по умолчанию, как и были. Но после задания значения переменной jQuery.var() значения будут меняться.
Там логика проста, при привязке тег просто добавляется в список тегов с именем переменной. Но после присвоения значения переменной, программа проходится по списку по порядку и присваивает новое значения в теги которые находятся в с писке.
Т.е.
Если привязать тег и потом отвязать но значение тега НЕ изменится.
Много разработчиков используя jQuery подключают дополнительно весь React

Что, простите? Вы вообще реакт видели?
Никто из тех, кто использует react, не будет тащить в проект jquery. Разве что в каких-нибудь ну очень экзотических случаях.


А я отвечу, что ведь потому и не удовлетворяет, что в нем не было простых всем нужных функций.
Если бы они были всем нужны, они бы там появились, уверяю.

Плагинов для привязки данных к элементам в своё время были сотни, если не тысячи (и у меня, и, думаю, у других здесь были свои велосипеды для этого), но все они закономерно умерли вместе с jquery.

Плагинов для привязки данных к элементам в своё время были сотни, если не тысячи (и у меня, и, думаю, у других здесь были свои велосипеды для этого), но все они закономерно умерли вместе с jquery.

Целая JavaScriptMVC была. На jQuery основанная.

И backbone с marionette были.

Посмотрел библиотеки эти. Очень они мудреные.
Преимущество есть, там можно привязывать списки объектов.
Вот привязка списка по шаблону:
jQuery().event('listUsers','.listUser',function(){ 
    let html = '';
    for(let user of this){
        html += "<div> <span>${user.FirsName}</span>  <span>${user.LastName} зарплата:  ${user.Amount} ₽ </div>"
    }
    return html;
})
Полно таких случаев. Только люди не всегда об этом знают.
Они тянут в проект какой-нибудь react-slick (8.6k звезд на гитхабе, 677k weekly downloads, 1.1k зависимых пакетов) и думают что они таки модные, впилили в реакт клёвую карусельку — а там в зависимостях jQuery.
Там jQuery заявлен не в Dependencies, а в Dev Dependencies.
Удивительно, но это оказывается порт, а не адаптер. А во Vue именно адаптер и там jQuery точно тянется. И в конкурирующей библиотеке Owl тоже тянется.

Ну так и в статье ровно наоборот написано )


Те у кого (по разным причинам) есть jQuery иногда тащат себе ещё и реакт для вот такого вот интерактива реактивного. Хотя могли обойтись имеющимся jQuery.


Была ещё дельная статья про страдание тех кто по разным причинам живёт с динозаврами: https://css-tricks.com/reactive-jquery-for-spaghetti-fied-legacy-codebases-or-when-you-cant-have-nice-things/ (из текста ссылки в принципе уже все понятно)


То что иногда без надобности используют что первое, что второе, когда можно было на ваниле 5ю строчками обойтись я умолчу )

Нативный JS имеет уже больше полезных функций и методов, чем jQuery. Почему бы вам не попробовать написать то же самое для нативного JS? При правильном подходе его можно сделать еще удобнее и даже быстрее.

Задача плагина Events быть понятным, простым для новичков, и выполнять свои функции для тех у кого уже подключен jQuery.


В 2020 году поощрять использование jQuery, на мой взгляд, преступление. Сейчас он только мешает новичкам практиковать реально полезные навыки. На рынке много веберов со знанием jQuery, которые либо не нужны, либо их приходится учить с нуля.

Ага, как же, имеет он. Разве что querySelector в нативный JS завезли, а в остальном никаких изменений за 20 лет в той области, которую покрывает jQuery. jQuery по-прежнему является очень полезной библиотекой, в которой есть множество удобных функций. Если писать на чистом JS, то придётся реализовывать их самостоятельно или подключать другие библиотеки (лишь бы не jquery, правда?)


React/Vue/Angular — это всё фреймворки и их значние/незнание никак не коррелирует с jQuery. И задачи они решают разные.

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

Не методы, но тем не менее jQuery требуют — select2, datatable. jquery хорош тем, что он простой. Любой бекендер может его взять и нашлепать формочек и табличек в админку. А с react это уже не так, к бекендеру нужен еще и фронтендер. А в итоге все те же таблички и формочки, только стоят они теперь в 3-4 раз дороже. А если в реакт затащить еще и редакс, то и в 10 раз дороже будет.
$('form').hide(600);
По Вашему как это реализовать на ваниле с анимацией?
PS я модернизировал скрипт, он поддерживает динамические массивы.

В целом, все верно говорите. Но если посмотреть конкретно на библиотеку, описываемую в статье — там из всего jquery используется $(selector).html(). Что вполне можно заменить на нативные методы.

Да даже тут не все так просто. Если кому-то приспичит использовать библиотеку для SVG-узлов, то с ванилой его ждут проблемы — часть методов в IE превратятся в тыкву (тот же innerHTML).
И там куча таких нюансов, о которых знают авторы jQuery, но не знают крикуны «жиквери нинужен, всё делается нативно!» :)

Но в целом я согласен, что ради одной строчки можно было бы и постараться. Хотя с другой стороны, какая разница, если плагин все равно написан плохо (как минимум, засирает глобальное пространство имён).
только что исправил все VAR на const и let.
Так чем же он плох?
Пожалуйста опишите список критериев плохого качества.
Я этот плагин за 3 дня накатал, Это как бы RC1 версия.
1. Подразумевался сам объект jQuery, который играет роль глобального пространства имен для плагинов. Хорошим тоном считается упаковать весь плагин в одну сущность jQuery.fn.pluginName.
2. Непонятно зачем привязывать к переменной селектор, когда в jQuery принято и всем привычно идти от селектора. И обращаться к нему через $.
3. Методы ничего не возвращают, то есть чейнинга нет.

Итого, плагин игнорирует все писанные и неписанные правила экосистемы jQuery, он чужероден в ней. Конечно, автор имеет право на свое виденье, но при чем тут тогда jQuery, тогда нужно писать независимую библиотеку.
Вроде возращают this везде методы плагина.
1. Если плагин упаковать в одну сущность jQuery.fn.pluginName. То тогда смысл и удобство теряется, использования плагина.
2. Переменную к селектору привязывается для абстракции логики. В популярных CMS на PHP функциональность и шаблоны отделены отдельно в добавок отделены от статей. Т.е. в автору не нужно писать внутри материала стили CSS и код формы обратной связи.
Плагин Events нужен для разделения друг от друга Дизайна от Логики программы. Чтобы при написании логики разработчику было не нужно каждый раз думать о символе рублей в конце показываемых сумм и других надписей.
В добавок удобно реализовать поддержку разных языков локализаций.
Логика кода остается не тронута, при этом можно менять строки форматирования отдельно.
Уже подумывал адаптировать к эти методы к объектам HTML элементам на ванильном JS.
Вот даже не знаю, новый репозиторий создавать или как?
В целом нет пока мысли чтобы писалось красиво на ванильном пользователям при использовании библиотеки.
Возможно:
Binder.Event(...);
Binder.Event(...);
Binder.Var(...);

let bind1 = new Binder();
bind1.event(....);
bind1.event(....);
bind1.var(....);
bind1.var(....);

Не соглашусь. Здесь человек решил задачу "сделать просто и понятно", а по вашей ссылке какой-то зубодробительный синтаксис и с ходу не понятно как это работает.

В точку. Сложное должно работать просто.
Многие придумывают простые библиотеки со сложной инструкцией.
Задача в том чтобы не думать об инструментах при разработке, а думать только о своей поставленной задаче при использовании инструмента.

Очевидное улучшение – не писать jQuery().event на каждый контрол, а делать один вызов и передавать туда объект, например так:


jQuery().event({
  ".selector1": function(){ /*action1*/ },
  ".selector2": function(){ /*action2*/ }
})

Если думать дальше – имеет смысл сделать отдельные ветки для объекта с данными и с привязкой контролов к данным:


{
  data: {text: "wow", val: 42},
  ui:{
    ".title": function(data){ return data.text },
    ".value": function(data){ return data.val }
  }
}

А если ещё немного подумать и порешать кучу сопутствующих задач типа условного форматирования, привязки инпутов, пересчёта зависимостей, асинхронной инициализации и пр – то как раз и получится jQuery.my.


Кстати, для jQuery-плагинов чётко специфицирован рекомендуемый формат вызовов: если первый аргумент – строка, то она должна быть запрашиваемым действием, типа там "init" или "update".

Очевидное улучшение – не писать jQuery().event на каждый контрол, а делать один вызов и передавать туда объект, например так:

jQuery().event() и jQuery().var() — методы для разделения логики интерфейса от бизнес логики.
Использование в jQuery().event() массив объектов для групповой привязки ни чего функционального не добавляет. Легко реализовать в for(){}, ну и если конечно добавить Ваше предложение, то это увеличит модуль и его разработку в 5 раз, при этом усложнит синтаксис. А если Вы поучавствуете в разработке то мы с Вами добавим новый функционал.

Если думать дальше – имеет смысл сделать отдельные ветки для объекта с данными и с привязкой контролов к данным:

Если jQuery().event() легко привязывается к объектам
то что мешает писать так?
jQuery().event('data','.title','{text}');
jQuery().event('data','.value','{val}');

jQuery().var('data', {text:'wow',val:42});

Объясните почему нужно писать все объектом?, что это за такой код должен быть чтобы все слеплено было в одну соплю?
Если изначально задача была отделить макет от бизнес логики.
Да и мой пример выше делает это красивей, без написания слова function().

При разработке у меня была другая идея. Реализовать возможность как бы пространства имен.
jQuery('.form1').var(....);
jQuery('.form1').event(....);
и
jQuery('.form2').var(....);
jQuery('.form2').event(....);
в не видимости друг друга, что позволит использовать одинаковые имена переменных без конфликтов.

Идея с раздельными .var и .event так себе – потому что вы делаете два плагина вместо одного. Есть устоявшаяся практика и рекомендации jQuery https://learn.jquery.com/plugins/basic-plugin-creation/#minimizing-plugin-footprint.


Объединять в один объект (то, что вы называете «слепить в одну соплю») имеет смысл по очевидной причине: этот объект становится унитарным реюзабельным компонентом (в $.my они называются манифестами). Такой компонент, однажды определённый, можно будет инстанцировать на разные DOM-ноды, подставляя в данные новый объект. Термин «пространство имён» не очень подходит есчо. Каждый инстанс компонента – это, скорее, отдельный scope, а не отдельный namespace.


Есть дополнительный бонус: если написать сериализатор-десериализатор таких объектов в json (в $.my такой есть), эти компоненты можно а) писать-читать в NoSQL базу, б) объединять, в) просто обрабатывать как объекты, а не как код. То-есть вкладывать друг в друга как подчинённые компоненты, мёржить, использовать одни как генерики-прототипы для других более кастомизированных, и пр.


То-есть мёрж-экстенд это примерно так для $.my:


var app = {
  data:{x:0, y:0}, // дефолтные значения
  ui:{
    '.x':(data)=>data.x, 
    '.y':(data)=>data.y
  }
};
var data1 = {x:5, y:10}, 
    data2 = {x:15, z:20};
$('#node1').my(app, data1); // инстанс в #node1 покажет data1 
$('#node2').my( // расширенный инстанс в #node2 покажет data2
  $.extend(!0, {ui:{'.z':(data)=>data.z}}, app), // расширяем компонент
  data2 // передаём data2 как данные
);

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

2 вместо 1 плагина, ну да в общем то. Ну так у обоих методов крайне разное предназначение и логика. Иначе простота просто испарится.
Выгрузка и загрузка всех данных в массив, Вы правы было бы полезно. В принципе там выгрузка уже есть, jQuery().var()-выгружаются все переменные, jQuery().event()-выгружаются все методы, jQuery().event('varName')-выгружаются все события для переменной.
Наверно по Вашему совету добавлю и загрузку всех объектов, что-то вроде:
jQuery().event({}) и jQuery().event('varName',{}); загрузка всех событий и загрузка всех событий для переменной.
.
По поводу пространства имен, суть внутри плагина просто будет создаваться различные массивы для разных selector, и хранится все эти разные массивы как бы должны внутри плагина. Значит при вызове плагин смотрит строку селектора и начинает использовать только тот массив ключ которого совпадает с селектором.
Это было бы удобно для создания своего виджета, А как часто бывает вдруг внезапно по приказу свыше виджет нужно клонировать на главной странице сайта.
Да действительно если бы я придерживался требования делать все водном модуле, то решение было бы только одно, делать как плагин MY, от сюда возникают множество мучений и костылей и впихнуть все (не совместимое) в один метод, и это получится сделать только через объект с нужными именами свойств. И если бы я бы взялся бы делать по такому правилу, то, во-первых, была бы потеряна главная идея простота. Во-вторых, второго аналогичного велосипеда с другим именем просто не нужно, никому. Поэтому я согласен с Вами что модуль этот, по сути, должен был быть аналогичный велосипед, но не доделанный, но я не соглашусь с тем, что нужно делать ущербный инструмент в угоду правила 1 вместо 2 модулей.

Постойте!..
А как в jQuery.my делать так?
jQuery.event('varOne', '.title');
jQuery.event('varTwo', '.description');


jQuery.var('varOne', 'Заголовок');
jQuery.var('varTwo', 'Текст');
Как в jQuery.My в коде привязку переменных к тегам отделить от задания значения переменного. чтобы например в инициализаторе можно было привязку сделать, а уже в обработчиках событий использовать присвоение значений переменным?

Не уверен, что понял вопрос, но всё же:


$('#parentDiv').my({
  data: {x:1, y:2},
  ui:   {'#x':'x', '#y':'y'} 
});
// чтобы поменять значение извне, используем
// соглашение jquery на команды для плагинов
$('#parentDiv').my('data', {x:15}); // обновится только x

Кроме 'data' у инстанса ещё довольно много других команд, вот тут http://jquerymy.com/api.html#CW-external-c все.

Я дополнил плагин новым функционалом,
Посмотрите пожалуйста в описании паблика ДОПОЛНЕНИЕ ниже.
Хочу узнать Ваше мнение, вроде как одно дело делаем, с Вами пытаемся jQuery популизировать. (на github версию обновлю в на днях)
Вот такой вариант поддерживается.
$.e({x:'#x', y:'#y'});
$.v({x:15, y:2});

Что такое условное форматирование?
Что такое пересчет зависимостей?
Идея хорошая «Асинхронная инициализация». Это типа привязка к переменным декларативным способом?
<div events-var='userName' events-format=' Приветствуем {value} ' events-load='user-init();'></div>

Условное форматирование – как в Экселе: если значение отвечает условию 1 (условие – функция), присвоить css .red (а если не отвечает – снять класс .red), если отвечает условию 2 – присвоить/снять класс .blue, и тд.


Пересчёт зависимостей – тоже примерно как в Экселе: если есть инпут #X, инпут #Y и див #R в котором X*Y, див надо пересчитывать на каждое изменение X или Y.


Асинхронная инициализация – это когда вы форму стартуете, а она промис вернула (или оригинальный jQuery object, расширенный промисом, так можно и цепочку не ломает), и ресолвит его только когда закончила зависимости грузить, данные обновлять, рисовать и пр.

Я дополнил плагин новым функционалом,
Посмотрите пожалуйста в описании паблика ДОПОЛНЕНИЕ ниже.
Хочу узнать Ваше мнение, вроде как одно дело делаем, с Вами пытаемся jQuery популизировать. (на github версию обновлю в на днях)

Не, автор не дотянул, но думает в том же направлении ))

Я просто создал библиотеку конкурирующую jQuery.MY() которая была создана Вами.
1.$.event() имеет черновой вариант. Но благодаря отзывам тут я исправлю все ошибки.
2.$.event() имеет простоту и красоту минимализма.
3.$.event() новых ф-й кроме как «выгрузки/загрузки», «пространства переменных» и «привязка списков с шаблоном» в принципе не будет получать новых функций, которые являются избыточными. Доп.фунции будут перегружать мозг пользователя. Здесь же красота простоты. И уровень входа в библиотеку крайне низок, а это и есть цель библиотеку упростить жизнь.
конкурирующую jQuery.MY()

)) Ок. У меня правда реактивное связывание и из коробки распознаётся куча контролов, то-есть:


$('#parentDiv').my({
  data: {x:1, y:2},
  ui:   {'#x':'x', '#y':'y'}
})

… привяжет проперти x к DOM-ноде #x вне зависимости от того, что там за нода. Если там div – просто покажет значение; если там input – свяжет этот инпут так, что если в него что-то написать, то в объекте с данными тоже значение обновится; если там например инстанцирован плагин типа select2 или $.ui.slider – реактивно свяжет сразу с плагином полностью скрывая всю многословную механику взаимодействия с ним и отлова его событий.


Доп.фунции будут перегружать

Это как посмотреть. Мультиметоды сильнее перегружают – то-есть когда у вас от аргументов существенно зависит что метод делает, это нехорошо, дохрена всего помнить надо. Чтобы этого избежать и придуманы в соглашении для jquery-плагинов команды – то-есть для анбайнда лучше делать $(selector).event('unbind', 'varName'); для обновления – $(selector).event('update', newValue) и тд. Команды – не самая красивая идея, но точно лучше кучи неочевидных сигнатур одной функции, особенно если вы минимализм декларируете.


Даже просто с точки зрения читаемости лучше: сразу понятно, что написано unbind, не надо угадывать, что там в переменных, которые вы как параметры передали.


В общем, дерзайте ))

Я дополнил плагин новым функционалом,
Посмотрите пожалуйста в описании паблика ДОПОЛНЕНИЕ ниже.
Хочу узнать Ваше мнение, вроде как одно дело делаем, с Вами пытаемся jQuery популизировать. (на github версию обновлю в на днях)
Минусы, которые я нашел:

1) Код не выложен на npm или хотя бы на cdn
2) Код не может быть импортирован через require / ES modules
3) Используются var'ы вместо let / const
4) Используется массив arguments вместо rest параметров
5) Форматирование кода хромает, где-то есть пробелы / переводы строк, где-то нет
6) String.prototype.format — изменяет прототип String, это очень плохой подход, так как это изменение затронет строки по всей программе
7) Просить донаты в комментариях к коду? Рили?

Как-то так
Я GitHub ом пользоватся не умею. Закачивал туда код через копипаст в веб интерфейсе.
если подскажите что надо изменить для require / ES modules и я досих пор не пойму RequireJS это отдельная библиотека или это нативный код?
подскажите как правильно модулность делать в для нативного JS?
За все Ваши замечания большой респект и уважуха. Я Выпишу этот список в ГитХаб
Я GitHub ом пользоватся не умею.

Очень-очень рекомендую поставить себе git и научиться. Без системы управления версиями разработка — это не разработка к мазохизм.
Я лично сделал это по справке, причём, не зная английского языка. Если Вы читаете по английски — проблем вообще быть не должно.

Очень прошу Вас напишите пожалуйста код require / ES modules.
Я пытался использовать require, но если это такая библиотека JS, то не понятно как такой способ работает нативно. А если это не может работать без библиотеки, тогда почему нельзя использовать ES modules?

Вам больше подойдёт шаблон UMD. Это такая обёртка, которая экспортирует объект разными способами, в зависимости от того, какие доступны.


Здесь описание https://github.com/umdjs/umd


Там есть пример плагина, хотя, не знаю насколько стандартен предлагаемый автором подход.
https://github.com/umdjs/umd/blob/master/templates/jqueryPlugin.js

Подскажите пожалуйста.
Я вот сейчас исправляю ошибки в плагине указанные Вами. (хочу добиться правильного кода).
Вопросик. А в чем правильность использования REST вместо ARGUMENTS параметров функции?
По нескольким причинам:
1) arguments — на самом деле не совсем массив. В нем нет некоторых встроенных методов, что может создавать проблемы. Rest оператор вернет обычный массив
2) Удобно — в rest массив попадают не все аргументы, а только те, которые ожидаются
3) И банально со стандарта ES6 написание кода через rest параметры более предпочтительно
Много разработчиков используя jQuery подключают дополнительно весь React чтобы только связывать переменные.


Необязательно, есть и компактные решения, проверенные временем. Например knockoutJS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации