Любая библиотека ставит в зависимость от себя.
Мне одно не понятно, почему Вы так «мечтаете о том дне, когда это закончится»? Лишние зависимости? Отсутствие нативной поддержки? Или что Вам, уважаемый, спать спокойно не даёт?)
Это отдельный сервис, никак не связанный с jquery.
Осмелюсь поправить Вас — Это отдельный сервис, связанный с jQuery уважаемого Джона Резига структурой и философией, но нацеленный на более широкие нужды.
хотя на мой взгляд стандартную функциональность лучше просто оборачивать в полифил.
Эх, если бы Javascript поддерживал методы расширения, как в C# или мета-классы, как в Groovy, которые не засоряли бы стандартные прототипы, но вызывались бы как функции прототипа, было бы очень здорово. В ES6, случаем, не намечается чего-то подобного?
Исходя из изученного мной за всё время работы с JS, я убедился, что расширение прототипов — не есть хорошо. По многим причинам. Хотя сам иногда этим балуюсь — в текущем положении JS не всё хорошо со стандартным набором функционала.
Однако же, мой пример из статьи — это далеко не .map() или что-то ещё. Представьте, что у вас есть большой набор каких-то данных и вам нужно отобрать из него выборку по определенным критериям. Что мы делаем на «чистом» JS? мы отбираем их через .filter() c функцией как аргумент. Если же нам нужно вызывать тот же самый .filter() несколько раз в разных местах, мы сохраняем функцию-аргумент в переменную и вызываем в нескольких местах, где она доступна.
Окей, теперь мой случай — я пишу функцию единожды, сохраняю её в объект jQuery.expr с нужным мне ключом (пусть это будет банальный odd из примера в статье) и вызываю что-то вроде jQuery('odd') в любом месте, где мне это будет необходимо (конечно же, в том контексте, где доступен jQuery, в большинстве случаев он глобален). Если же мне где-то нужно вызывать другую функцию, я делаю то же самое, ну а если мне в одном месте понадобится какая-то особая логика отбора, я вместо строки передаю туда функцию, которая отберёт мне мои данные. Предполагается, что программист научит Builder понимать как можно больше типов селекторов.
Приведу пример из моей разработки для Adobe After Effects (статья о которой скоро будет на Хабре):
jQuery(':active') // выбираем только те слои, которые отмечены, как активные (":" - управляющий символ, говорящий о том, что сейчас нужно будет найти функцию из jQuery.expr), active - ключ в jQuery.expr, по которому находится отбирающая функция
jQuery(1) // Получаем один слой, индекс которого равен единице
jQuery('Layer 1') // Получаем слои, имя которых равняется Layer 1
jQuery(/TextLayer \d+/) // Получаем слои, имя которых соответствует регулярному выражению
jQuery([1, 'Layer 1', 'Layer 2']) // Получаем слои, которые подходят под условия каждого элемента массива.
// и так вплоть до предела нашей фантазии
И всё почти точно так же, как в браузерном jQuery. Можно к примеру сделать какой-нибудь парсер расширенных селекторов.
В каждой из этих выборок лежит набор предопределённых программистом методов, с помощью которых он может управлять всей выборкой без лишних движений.
Примеры с числами и строками — лишь пример для подачи идеи.
В следующей статье я буду перебирать слои в Adobe After Effects и манипулировать ими — как результат. А затем — слои Фотошопа (если разберусь с ними, конечно). Ещё была практика внедрения Builder'а в Google Drive для работы с файлами на моём Диске. Получалось достаточно просто, но в некоторых случаях помогало очень. К примеру, если мне нужно найти определенную выборку файлов по хитрозакрученным критериям и что-нибудь с ними сделать (банальный пример — удалить).
Я смотрю, утрированное понятие «шедевр» привлекло внимание читателей больше, чем сама статья)
Ну, нет же, мне просто нравится jQuery, какой он есть сейчас.
ИМХО на покой jQuery отправится ещё не скоро (к сожалению или к счастью — не знаю).
С развитием языка Javascript и внедрением его всеми-кому-не-лень во-все-какие-можно-дыры (Node, Adobe, Google Drive, Unity? и пр.) становится как-то не по себе — а что, собсна будет дальше? Мне, как человеку, знакомому с языком «выше среднего», весьма интересен ответ на этот вопрос.
По поводу нативности — очень сомневаюсь. Хотя догадки возникали ещё года 3 назад.
Беспощадные минусаторы :(
Я репозиторий развернул, можно сказать, на коленке, предварительно прогнав через него несколько примеров, используя код, который написал с ~полгода назад.
Вот, рассказал об идее на Хабре, пока у людей впечатлений мало. Да, в этом моя вина — не достаточно ёмко.
За ближайшую пару недель постараюсь найти время и довести всё до ума. Моей задачей несколько дней назад была демонстрация самой идеи. Разработка, поддержка и натирание напильником доработка — всё в будущем, ближайшем, конечно же.
Вопрос к знатокам.
Как-то я пытался разработать что-то подобное на Java. Но выглядело это несколько иначе. Если в моём слуачае на JS мы создаём instance конструктора jQueryBuilder с указанием функции-конструктора как аргумент, то на Java это был родительский класс со прописанными стандартными методами (each, map, etc), от которого наследовался класс с необходимым программисту функционалом. Есть ли смысл реализовывать то же самое на JS?
Я унаследовал jQuery (который получается на выходе) от стандартного массива.
И да, цель статьи, да и вообще самой библиотеки — показать, как устроен jQuery и что с этим можно сделать. По поводу использования\не использования чего-либо в коде — прошу всех в репозиторий.
Никакого оригинального jQuery, который весит 100k (а то и больше) тащить с собой не нужно.
В общем кто-то из нас не понял другого.
Мне одно не понятно, почему Вы так «мечтаете о том дне, когда это закончится»? Лишние зависимости? Отсутствие нативной поддержки? Или что Вам, уважаемый, спать спокойно не даёт?)
Осмелюсь поправить Вас — Это отдельный сервис, связанный с jQuery уважаемого Джона Резига структурой и философией, но нацеленный на более широкие нужды.
Эх, если бы Javascript поддерживал методы расширения, как в C# или мета-классы, как в Groovy, которые не засоряли бы стандартные прототипы, но вызывались бы как функции прототипа, было бы очень здорово. В ES6, случаем, не намечается чего-то подобного?
Однако же, мой пример из статьи — это далеко не .map() или что-то ещё. Представьте, что у вас есть большой набор каких-то данных и вам нужно отобрать из него выборку по определенным критериям. Что мы делаем на «чистом» JS? мы отбираем их через .filter() c функцией как аргумент. Если же нам нужно вызывать тот же самый .filter() несколько раз в разных местах, мы сохраняем функцию-аргумент в переменную и вызываем в нескольких местах, где она доступна.
Окей, теперь мой случай — я пишу функцию единожды, сохраняю её в объект jQuery.expr с нужным мне ключом (пусть это будет банальный odd из примера в статье) и вызываю что-то вроде jQuery('odd') в любом месте, где мне это будет необходимо (конечно же, в том контексте, где доступен jQuery, в большинстве случаев он глобален). Если же мне где-то нужно вызывать другую функцию, я делаю то же самое, ну а если мне в одном месте понадобится какая-то особая логика отбора, я вместо строки передаю туда функцию, которая отберёт мне мои данные. Предполагается, что программист научит Builder понимать как можно больше типов селекторов.
Приведу пример из моей разработки для Adobe After Effects (статья о которой скоро будет на Хабре):
И всё почти точно так же, как в браузерном jQuery. Можно к примеру сделать какой-нибудь парсер расширенных селекторов.
В каждой из этих выборок лежит набор предопределённых программистом методов, с помощью которых он может управлять всей выборкой без лишних движений.
В следующей статье я буду перебирать слои в Adobe After Effects и манипулировать ими — как результат. А затем — слои Фотошопа (если разберусь с ними, конечно). Ещё была практика внедрения Builder'а в Google Drive для работы с файлами на моём Диске. Получалось достаточно просто, но в некоторых случаях помогало очень. К примеру, если мне нужно найти определенную выборку файлов по хитрозакрученным критериям и что-нибудь с ними сделать (банальный пример — удалить).
Как насчёт того, что я описал в статье?
Ну, нет же, мне просто нравится jQuery, какой он есть сейчас.
ИМХО на покой jQuery отправится ещё не скоро (к сожалению или к счастью — не знаю).
С развитием языка Javascript и внедрением его всеми-кому-не-лень во-все-какие-можно-дыры (Node, Adobe, Google Drive, Unity? и пр.) становится как-то не по себе — а что, собсна будет дальше? Мне, как человеку, знакомому с языком «выше среднего», весьма интересен ответ на этот вопрос.
По поводу нативности — очень сомневаюсь. Хотя догадки возникали ещё года 3 назад.
Я репозиторий развернул, можно сказать, на коленке, предварительно прогнав через него несколько примеров, используя код, который написал с ~полгода назад.
Вот, рассказал об идее на Хабре, пока у людей впечатлений мало. Да, в этом моя вина — не достаточно ёмко.
За ближайшую пару недель постараюсь найти время и довести всё до ума. Моей задачей несколько дней назад была демонстрация самой идеи. Разработка, поддержка и
натирание напильникомдоработка — всё в будущем, ближайшем, конечно же.Как-то я пытался разработать что-то подобное на Java. Но выглядело это несколько иначе. Если в моём слуачае на JS мы создаём instance конструктора jQueryBuilder с указанием функции-конструктора как аргумент, то на Java это был родительский класс со прописанными стандартными методами (each, map, etc), от которого наследовался класс с необходимым программисту функционалом. Есть ли смысл реализовывать то же самое на JS?
И да, цель статьи, да и вообще самой библиотеки — показать, как устроен jQuery и что с этим можно сделать. По поводу использования\не использования чего-либо в коде — прошу всех в репозиторий.