Комментарии 50
В последствии чего задав новое значение переменной все привязанные теги на странице обновятся.Если я правильно понял, все привязанные теги на странице сначала зададут новое значение переменной в каком-то последствии (не указано, последствии чего), а потом обновятся?
Там логика проста, при привязке тег просто добавляется в список тегов с именем переменной. Но после присвоения значения переменной, программа проходится по списку по порядку и присваивает новое значения в теги которые находятся в с писке.
Т.е.
Если привязать тег и потом отвязать но значение тега НЕ изменится.
Много разработчиков используя 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 иногда тащат себе ещё и реакт для вот такого вот интерактива реактивного. Хотя могли обойтись имеющимся jQuery.
Была ещё дельная статья про страдание тех кто по разным причинам живёт с динозаврами: https://css-tricks.com/reactive-jquery-for-spaghetti-fied-legacy-codebases-or-when-you-cant-have-nice-things/ (из текста ссылки в принципе уже все понятно)
То что иногда без надобности используют что первое, что второе, когда можно было на ваниле 5ю строчками обойтись я умолчу )
Задача плагина Events быть понятным, простым для новичков, и выполнять свои функции для тех у кого уже подключен jQuery.
В 2020 году поощрять использование jQuery, на мой взгляд, преступление. Сейчас он только мешает новичкам практиковать реально полезные навыки. На рынке много веберов со знанием jQuery, которые либо не нужны, либо их приходится учить с нуля.
Ага, как же, имеет он. Разве что querySelector в нативный JS завезли, а в остальном никаких изменений за 20 лет в той области, которую покрывает jQuery. jQuery по-прежнему является очень полезной библиотекой, в которой есть множество удобных функций. Если писать на чистом JS, то придётся реализовывать их самостоятельно или подключать другие библиотеки (лишь бы не jquery, правда?)
React/Vue/Angular — это всё фреймворки и их значние/незнание никак не коррелирует с jQuery. И задачи они решают разные.
Большое половины методов jquery уже не нужны в типовых проектах, а в крупных они даже мешают, и порой самостоятельно можно написать более производительные аналоги методов jquery.
Я уже года три не практикую jquery, поэтому мне было бы интересно узнать от текущих пользователей, какие методы jquery полезны и востребованы сейчас?
$('form').hide(600);
По Вашему как это реализовать на ваниле с анимацией? PS я модернизировал скрипт, он поддерживает динамические массивы.
В целом, все верно говорите. Но если посмотреть конкретно на библиотеку, описываемую в статье — там из всего jquery используется $(selector).html()
. Что вполне можно заменить на нативные методы.
И там куча таких нюансов, о которых знают авторы jQuery, но не знают крикуны «жиквери нинужен, всё делается нативно!» :)
Но в целом я согласен, что ради одной строчки можно было бы и постараться. Хотя с другой стороны, какая разница, если плагин все равно написан плохо (как минимум, засирает глобальное пространство имён).
Так чем же он плох?
Пожалуйста опишите список критериев плохого качества.
Я этот плагин за 3 дня накатал, Это как бы RC1 версия.
2. Непонятно зачем привязывать к переменной селектор, когда в jQuery принято и всем привычно идти от селектора. И обращаться к нему через $.
3. Методы ничего не возвращают, то есть чейнинга нет.
Итого, плагин игнорирует все писанные и неписанные правила экосистемы jQuery, он чужероден в ней. Конечно, автор имеет право на свое виденье, но при чем тут тогда jQuery, тогда нужно писать независимую библиотеку.
2. Переменную к селектору привязывается для абстракции логики. В популярных CMS на PHP функциональность и шаблоны отделены отдельно в добавок отделены от статей. Т.е. в автору не нужно писать внутри материала стили CSS и код формы обратной связи.
Плагин Events нужен для разделения друг от друга Дизайна от Логики программы. Чтобы при написании логики разработчику было не нужно каждый раз думать о символе рублей в конце показываемых сумм и других надписей.
В добавок удобно реализовать поддержку разных языков локализаций.
Логика кода остается не тронута, при этом можно менять строки форматирования отдельно.
Вот даже не знаю, новый репозиторий создавать или как?
В целом нет пока мысли чтобы писалось красиво на ванильном пользователям при использовании библиотеки.
Возможно:
Binder.Event(...);
Binder.Event(...);
Binder.Var(...);
let bind1 = new Binder();
bind1.event(....);
bind1.event(....);
bind1.var(....);
bind1.var(....);
Вы изобрели https://github.com/ermouth/jQuery.my
Не соглашусь. Здесь человек решил задачу "сделать просто и понятно", а по вашей ссылке какой-то зубодробительный синтаксис и с ходу не понятно как это работает.
Многие придумывают простые библиотеки со сложной инструкцией.
Задача в том чтобы не думать об инструментах при разработке, а думать только о своей поставленной задаче при использовании инструмента.
Очевидное улучшение – не писать 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 как данные
);
Если вы собираетесь делать что-то большее, чем небольшой статический шаблонизатор (их полно и так, и есть куда короче вашего), вам не избежать усложнения инструмента для упрощения записи компонентов для него.
Выгрузка и загрузка всех данных в массив, Вы правы было бы полезно. В принципе там выгрузка уже есть, 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 версию обновлю в на днях)
Не, автор не дотянул, но думает в том же направлении ))
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) Просить донаты в комментариях к коду? Рили?
Как-то так
если подскажите что надо изменить для require / ES modules и я досих пор не пойму RequireJS это отдельная библиотека или это нативный код?
подскажите как правильно модулность делать в для нативного JS?
За все Ваши замечания большой респект и уважуха. Я Выпишу этот список в ГитХаб
Я пытался использовать 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
Плагин Events для jQuery