Jquery заменить класс: Jquery замена класса? — Хабр Q&A

Как отказаться от jQuery в современном фронтенде: опыт команды GitHub

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

Зачем jQuery был нужен раньше?

jQuery 1.2.1 вошёл в число зависимостей GitHub в конце 2007 года. Это произошло за год до того, как Google выпустил первую версию браузера Chrome. На тот момент не было общепринятого способа обращаться к элементам DOM с помощью CSS-селектора, не было стандартного способа добавить анимацию к стилю элемента, а интерфейс XMLHttpRequest, предложенный Internet Explorer, как и многие API, был плохо совместим с браузерами.

С jQuery стало гораздо проще управлять DOM, создавать анимации и делать AJAX-запросы. У веб-разработчиков появилась возможность создавать более современные, динамические сайты, которые выделялись среди остальных. Самое главное, все функции JavaScript, проверенные в одном браузере с помощью jQuery, как правило, работали и в других браузерах. На заре GitHub, когда большинство его функций только обретали форму, появление jQuery позволило небольшой команде разработчиков быстро создавать прототипы и представлять новые функции без необходимости подстраивать их отдельно под каждый браузер.

Простой интерфейс jQuery также послужил основой для создания библиотек, которые в будущем стали компонентами остальной части фронтенда GitHub.com: pjax и facebox.

Веб-стандарты в последующие годы

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

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

• Шаблон $(selector) можно легко заменить на querySelectorAll();
• Переключение CSS-классов теперь можно осуществить с помощью Element. classList;
• CSS теперь поддерживает создание анимации в таблицах стилей, а не в JavaScript;
• $.ajax-запросы можно выполнять с помощью Fetch Standard;
• Интерфейс addEventListener() достаточно стабилен для кроссплатформенного использования;
• Шаблон делегирования событий легко инкапсулировать с помощью легковесной библиотеки;
• С эволюцией JavaScript часть синтаксического сахара jQuery устарела.

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

$('.js-widget')
  .addClass('is-loading')
  .show()

Такой синтаксис прост в написании, однако по нашим стандартам не очень хорошо передаёт намерения автора. Сколько элементов js-widget, по его задумке, должно быть на странице: один или больше? А если мы обновим разметку страницы и случайно оставим имя класса js-widget, будет ли выброшено исключение, которое сообщит нам, что что-то пошло не так? По умолчанию jQuery молча пропускает всё выражение, когда нет совпадений по начальному селектору; однако для нас такое поведение было больше багом, нежели фичей.

Наконец, нам хотелось начать аннотировать типы с Flow, чтобы проводить статическую проверку типов во время сборки, и мы пришли к выводу, что синтаксис цепочек плохо поддаётся статическому анализу, так как почти каждый результат вызова метода jQuery одного и того же типа. Из возможных вариантов мы выбрали именно Flow, так как тогда такие возможности, как режим @flow weak, позволили нам начать прогрессивно и эффективно применять типы к кодовой базе, которая по большей части была нетипизированной.

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

Постепенный переход

Хотя наша конечная цель была не за горами, мы знали, что было бы нецелесообразно направить все имеющиеся ресурсы на переписывание всего с jQuery на чистый JS. Во всяком случае, такое поспешное решение негативно бы сказалось на функциональности сайта, от которой нам бы пришлось отказаться. Вместо этого мы:

• Начали отслеживать количество вызовов jQuery на строку кода и следили за графиком на протяжении времени, чтобы убедиться, что он либо не меняется, либо падает, но не растёт.
• Отказались от использования jQuery в новом коде. Чтобы достичь этого с помощью автоматизации, мы создали eslint-plugin-jquery, который проваливал CI-тесты при попытке использовать возможности jQuery вроде $.ajax.
• В старом коде появилось много нарушений правил eslint, которые мы пометили с помощью специальных правил eslint-disable
  в комментариях. Для того, кто будет это читать, такие комментарии должны были служить явным сигналом того, что здесь не отражаются наши текущие методы написания кода
• Мы написали бота, который при отправке pull request’а оставлял комментарий, сигнализирующий нашей команде каждый раз, как кто-то хотел добавить новое правило eslint-disable. Таким образом мы могли провести ревью кода на ранней стадии и предложить альтернативы.
• Большая часть старого кода была явно связана с внешними интерфейсами jQuery-плагинов pjax и facebox, поэтому мы оставили их интерфейсы почти без изменений, в то время как изнутри заменили их реализацией на чистом JS. Наличие статической проверки типов вселило в нас уверенность в проводимом рефакторинге.
• Много старого кода было связано с rails-behaviors, нашим адаптером для Ruby on Rails, таким образом, что он присоединял обработчик жизненного цикла AJAX к определённым формам:

   // УСТАРЕВШИЙ ПОДХОД
    $(document).on('ajaxSuccess', 'form.js-widget', function(event, xhr, settings, data) {
      // вставка данных ответа куда-нибудь в DOM
    })

  Вместо того чтобы переписывать все эти вызовы согласно новому подходу, мы решили использовать ложные события жизненного цикла ajax*, и формы продолжали отправлять данные асинхронно, как и раньше; только теперь изнутри использовался fetch().

• Мы поддерживали свою сборку jQuery, из которой убирали ненужные нам модули и заменяли более лёгкой версией. Например, после избавления от всех jQuery-специфичных CSS-псевдоселекторов вроде :visible или :checkbox мы смогли убрать модуль Sizzle; а когда мы заменили $.ajax-вызовы на fecth(), мы смогли отказаться от модуля AJAX. Мы убивали двух зайцев разом: уменьшали время выполнения JavaScript, параллельно гарантируя то, что никто не напишет код, который будет пытаться использовать удалённую функциональность.
• Глядя на статистику нашего сайта, мы старались прекратить поддержку Internet Explorer настолько быстро, насколько это возможно. Как только использование определённой версии IE падало ниже определённого порога, мы прекращали её поддержку и фокусировались на более современных браузерах. Отказ от поддержки IE 8-9 на раннем этапе позволил нам использовать многие нативные возможности браузеров, которые в противном случае было бы сложно «заполифиллить».
• В рамках нашего усовершенствованного подхода к написанию фронтенда GitHub мы сосредоточились на использовании обычного HTML по-максимуму, добавляя JavaScript в качестве последовательного улучшения. В итоге даже те формы и другие элементы интерфейса, которые были улучшены с помощью JS, как правило, могли работать даже с выключенным в браузере JavaScript. В некоторых случаях нам даже удалось удалить определённую устаревшую функциональность вместо её переписывания на чистом JS.

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

Custom Elements: пользовательские элементы

Одна технология, наделавшая шуму в последние годы, — Custom Elements: библиотека компонентов, встроенная в браузер, что означает отсутствие необходимости для пользователя качать, парсить и компилировать дополнительные байты фреймворка.

Мы создали несколько пользовательских элементов на основе спецификации v0 с 2014 года. Однако, поскольку стандарты в то время постоянно менялись, мы сильно в это не вкладывались. А начали только с 2017 года, когда была выпущена спецификация Web Components v1, реализованная как в Chrome, так и в Safari.

Во время перехода с jQuery мы искали структуры, которые можно было бы извлечь в качестве пользовательских элементов. Например, мы преобразовали код facebox, использованный для отображения модальных диалогов, в элемент <details-dialog>.

Наша общая философия прогрессивного улучшения относится и к пользовательским элементам. Это значит, что мы стараемся хранить как можно больше контента в разметке и только добавлять поведение поверх неё. Например, <local-time> по умолчанию показывает исходную временную метку, но с улучшением может переводить время в местный часовой пояс, а <details-dialog>, расположенный внутри элемента <details>, интерактивен даже без JavaScript, но может быть улучшен до расширенных возможностей доступа.

Вот пример того, как можно реализовать элемент <local-time>:

// Элемент local-time отображает время в текущем
// часовом поясе и местоположении пользователя.
//
// Пример:
//   Sep 6, 2018
//
class LocalTimeElement extends HTMLElement {
  static get observedAttributes() {
    return ['datetime']
  }

  attributeChangedCallback(attrName, oldValue, newValue) {
    if (attrName === 'datetime') {
      const date = new Date(newValue)
      this.textContent = date.toLocaleString()
    }
  }
}

if (!window.customElements.get('local-time')) {
  window.LocalTimeElement = LocalTimeElement
  window.customElements.define('local-time', LocalTimeElement)
}

Один из аспектов Web Components, который мы очень хотим перенять, — Shadow DOM. У Shadow DOM есть потенциал для раскрытия множества возможностей для веба, однако он также усложняет полифиллинг. Так как его полифиллинг на данный момент приведёт к снижению производительности даже для кода, который управляет частями DOM, не относящихся к веб-компонентам, для нас нецелесообразно использовать его в продакшне.

Полифиллы

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

• github/eventlistener-polyfill
• github/fetch
• github/form-data-entries
• iamdustan/smoothscroll
• javan/details-element-polyfill
• jonathantneal/closest
• kumarharsh/custom-event-polyfill
• marvinhagemeister/request-idle-polyfill
• mathiasbynens/Array.from
• mathiasbynens/String.prototype.codePointAt
• mathiasbynens/String.prototype.endsWith
• mathiasbynens/String.prototype.startsWith
• medikoo/es6-symbol
• nicjansma/usertiming.js
• rubennorte/es6-object-assign
• stefanpenner/es6-promise
• webcomponents/template
• webcomponents/URL
• webcomponents/webcomponentsjs
• WebReflection/url-search-params
• yola/classlist-polyfill

Смотрите также: «Фундаментальные принципы объектно-ориентированного программирования на JavaScript»

Перевод статьи «Removing jQuery from GitHub. com frontend»

Alpine.js — лёгкая альтернатива jQuery

Я давно уже присматриваюсь к Alpine.js, поскольку этот js-фреймворк разительно выделяется из ряда других. По своей сути он очень близок к Vue.js, но при этом может работать как привычный jQuery.

Основной массе разработчиков просто не нужны все те «фишки», что предлагают React или Vue. Вообще работа с JavaScript всегда происходит по одному алгоритму — вначале получили элемент/элементы на странице, после делаем с ними какие-то манипуляции.

Точно также работает и система событий — прописали либо onclick к нужному html-элементу, либо навесили событие через «слушатель» addEventListener и дальше через js-функцию делаем что нужно. Поскольку JavaScript очень уж многословен, а во многих случаях и неочевиден, то и возникли библиотеки функций — jQuery как раз одна из них. С их помощью работать с js намного приятней.

Но современные js-фреймворки помимо своих функций, предлагают немного другой подход, основанный на синтаксическом «сахаре» — который не имеет никакого смысла вне используемого фреймворка. Такой синтаксис наверное даже удобней функций jQuery (и других аналогов).

За это приходится расплачиваться. Основное ограничение — такие фреймворки требуют для своей работы Node.js, поскольку исходный код нужно скомпилировать в полноценный JavaScript, который уже будет понимать браузер. Да, формально можно использовать готовые сборки того же React или Vue, но размер их js-файлов достаточно большой: 120 и 93Кб. Даже jQuery 3.5 весит меньше — 89Кб. Если мы хотим сэкономить на загрузке (а js-код критично важен для браузера), то нет смысла использовать тот же Vue. И это при том, что в таком варианте мы лишаемся всех «плюшек» синтаксического «сахара».

Использование Node.js тоже не имеет смысла, если нам нужно сделать какие-то простые вещи, вроде сменить css-класс или отследить click на кнопке. Ставить ради этого гигантский Node.js неразумно.

Alpine.js выделяется тем, что имеет очень небольшие размеры (всего 25Кб), не требует компиляции, но при этом поддерживает синтаксический «сахар» как и «большие» фреймворки.

Важно то, что Alpine.js можно загружать в конце BODY, что даёт прирост скорости страницы. Если jQuery (и аналоги) мы вынуждены загружать в секцию HEAD (поскольку в теле страницы произвольно могут встретиться её функции), то с Alpine.js мы вообще не задумываемся об этом. Достаточно прописать загрузку как обычный js-файл:

<script src="https://cdn.jsdelivr.net/gh/alpinejs/[email protected]/dist/alpine.min.js"></script>

После этого на странице можно использовать возможности Alpine.

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

Например нам нужно отследить обычный click на каком-то элементе. Обычно мы прописываем css-класс или уникальный id и потом цепляемся к нему с помощью события onclick, в котором прописываем функцию-обработчик.

В Alpine схема заимствованна из «больших» фреймворков (в основном — из Vue), где применяется компонентный подход. В нём мы объявляем, что какой-то элемент, например DIV будет являться компонентом, или в современных терминах — ему добавляется «реактивность». Такой компонент будет представлять собой единую сущность: со своими данным и поведением.

<div x-data>
	содержимое	
</div>

Директива x-data — это та самая инструкция, которая указывает Alpine добавить реактивности в данный блок. Всё, что окажется внутри — и будет представлять собой единый компонент.

В Alpine всего 14 директив и все они начинаются с префикса x-. Основная x-data не только указывает на сам компонент, но и позволяет сразу инициализировать данные.

<div x-data="{t: false}">
	содержимое
</div>

В данном примере будет создана переменная t со значением false. Поскольку это обычный js-объект, то в нём можно определить любые данные (или функцию, которая их вернёт).

Теперь сделаем простой пример, в котором будет отслеживать событие onclick при котором менять css-класс (аля-toggle).

<div x-data="{t: false}">
	<div x-on:click="t = !t" x-bind:class="{ 't-red': t }">Toggle class click</div>
</div>

Toggle class click

В x-data мы создаём переменную, которая будет хранить текущее состояние элемента. Директива x-on:click отслеживает событие onclick, где в кавычках указывается js-код — как будто-бы это обычная js-функция. В данном случае мы инвертируем значение t.

Дальше мы используем директиву x-bind, которая связывает атрибут тэга (здесь это class) с логическими выражениями. Конкретно в этом примере css-класс t-red добавится к этому элементу только, если t будет истинно (true).

Мы кликаем на элементе, меняется переменная t, которая влияет на bind-связку и css-класс автоматом добавляется. Второй клик инвертирует t и класс удаляется.

Этот же самый пример можно оформить ещё проще:

<div x-data="{t: false}">
	<div @click="t = !t" :class="{ 't-red': t }">Toogle class click</div>
</div>

То есть @ заменяется на x-on:, а : на x-bind:.

Можно не создавать оборачивающий блок, если это одиночный элемент:

<div x-data="{t: false}" @click="t = !t" :class="{'t-red': t}">Toogle class click</div>

Похожий пример, только отслеживаем событие аля-hover:

<div x-data="{t: false}">
	<div @mouseover="t = true" @mouseout="t = false" :class="{'t-red': t}">Toogle class hover</div>
</div>

Toogle class hover

Эти примеры очень похожи на то с чем мы постоянно сталкиваемся в jQuery: поменять css-класс при каком-то событии.

Рассмотрим ещё пару примеров. Этот мне особенно нравится:

<div x-data="{ open: false }">
    <button @click="open = true">Open</button>
    
    <div x-show="open" @click.away="open = false" x-cloak>
    	Content
    </div>
</div>

Content

Это обычный dropdown, который раскрывает блок контента по клику. Я использую классы Berry CSS, которые семантически понятны.

Здесь мы определяем переменную open, которая хранит состояние блока контента (скрыт/открыт). У блока контента используется директива x-show, которая содержит js-выражение. Если это false, то x-show скроет блок через display: none. Таким образом, кликнув на кнопку мы открываем блок контента через переменную open.

У контента есть ещё одна директива @click.away, которая указывает на клик, но вне этого блока. Именно поэтому, когда мы повторно кликаем на кнопку или любую другую часть страницы, переменная open становится false и блок скрывается.

Директива x-cloak, а точнее это атрибут тэга, особенная. Её назначение в том, чтобы исчезнуть как только Alpine будет проинициализирован. Смысл в том, что js-файл Alpine может загружаться дольше, чем браузер начнёт отображать страницу, а значит блоки, который по умолчанию должны быть скрыты — будут изначально показаны. И как только сработает Alpine они уже отобразятся как задумано. Вот эта задержка может приводить к неприятному «мельканию». Поэтому для таких блоков достаточно указать x-cloak, а в css-стилях прописать:

<style>
	[x-cloak] {display: none;}
</style>

Пока Alpine не загружена, блок будет скрыт. При этом нам не нужно что-либо ещё отслеживать.

Пример с dropdown может использовать и для меню, и для модальных окон. Мы по сути не написали ни строчки js-кода, а получили потрясающую функциональность. Это не сравнится ни с jQuery, ни с нативным JS.

Ну и последний пример — табы.

<div x-data="{ tab: 'foo' }">
    <button :class="{ 'bg-blue': tab === 'foo' }" @click="tab = 'foo'">Foo</button>
    <button :class="{ 'bg-blue': tab === 'bar' }" @click="tab = 'bar'">Bar</button>
 
	<div>
    	<div x-show="tab === 'foo'">Вкладка Foo</div>
    	<div x-show="tab === 'bar'" x-cloak>Вкладка Bar</div>
    </div>
</div>

Вкладка Foo

Вкладка Bar

Если вы когда-нибудь делали свои табы, то поймёте насколько компактным и универсальным получился этот код. Мне кажется, что более простой реализации и не существует…

Что в итоге? Для меня Alpine.js — настоящая находка, которая доказывает, что использовать js-интерактивность в html-коде можно просто и удобно. При этом возможности Alpine намного больше — многие из них рассчитаны на опытных js-разработчиков. Но и для обычных вебмастеров, которым нужно решать простые задачи, Alpine.js может пригодится как лёгкая замена jQuery.

Работа с Ajax в Alpine.js

Админ-панель для Albireo

Функция jQuery .closest() и альтернативы чистому JavaScript – clubmate.fi

Функция jQuery .closest() и альтернативы чистому JavaScript сведение к методу jQuery

.closest() и двум собственным альтернативам JavaScript.

Функция jQuery .closest() великолепна! Вот что он делает:

Для каждого элемента в наборе получить первый элемент, который соответствует селектору, проверяя сам элемент и просматривая его предков в дереве DOM.

По сути, у ближайшей функции есть две вещи:

1. Начальная точка — начните отсюда и пройдите DOM вверх.
2. Элемент для поиска — остановить ход при попадании в этот элемент и вернуть его.

Вот наш пример разметки, с которой мы будем работать:

 

  <навигация>
    <ул>
      
элемент1
      
элемент2
      
элемент 3
      
элемент4
    
  
 

Представьте, что вы хотите что-то сделать с nav , но ваша «отправная точка» — один из элементов li (по какой-то причине). У вас может возникнуть соблазн сделать это:

 $('.nav-item-1')
  .parent() // ул.
  .parent() // навигация
  .parent() // раздел
  .css('background-color', 'red') 

Это не так уж плохо, но что, если вам нужно пройти большее расстояние? Или если вы добавите туда обертку, вам нужно обновить код. Closest создан именно для таких вещей:

 $('.nav-item-1').closest('nav').css('background-color', 'red') 

Вы указываете начальную точку $('.nav-item-1 ') и конечную точку . closest('nav') , и он будет проходить через DOM до тех пор, пока не достигнет цели и не вернет ее.

Чистый JavaScript

NearestByClass function

Ниже приведена ванильная функция JavaScript, которая получает ближайший по имени класс. Из него гораздо подробнее можно увидеть, как на самом деле работает ближайшая функция:

 var NearestByClass = функция (эль, клазз) {
  // Обходим DOM вверх с помощью цикла while
  в то время как (el.className != clazz) {
    // Увеличиваем цикл до родительского узла
    эл = эл.родительский узел
    если (!эль) {
      вернуть ноль
    }
  }
  // В этот момент цикл while остановлен, и `el` представляет элемент
  // который имеет класс, указанный вами во втором параметре функции
  // `клаз`
  вернуть эль
} 

Пример использования:

 document.onclick = function (e) {
  if (closestByClass(e.target, 'какой-то класс')) {
    // Сделай что-нибудь
  } еще {
    // Делаем что-то еще
  }
} 

Это хорошо и все такое, но он принимает только имена классов, его легко проверить на ID, просто замените className на id . Хотя этого может быть вполне достаточно в большинстве случаев использования, он все еще не очень универсален.

Рекурсивный чистый JavaScript ближайший

Вот более гибкая функция, использующая рекурсию и немного короче:

 var Nearest = function (el, fn) {
  вернуть el && (fn(el) ? el : ближайший(el.parentNode, fn))
} 

Или запишите его как однострочный со стрелочной функцией:

 var ближайший = (el, fn) => el && (fn(el) ? el : ближайший(el.parentNode, fn)) 

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

 var srcEl = document.getElementsByClassName('nav__item-3')
// Элемент с классом `.nav` является нужным элементом в этом случае
var nav = ближайший (srcEl [0], функция (el) {
  // Прелесть этой функции в том, что у нас есть контроль над целью, здесь
  // мы используем имя класса `.nav`
  вернуть el. className === 'nav'
})
// Теперь переменная `nav` содержит ближайший элемент с классом `.nav`
console.log(навигация)
// Здесь цель указана как id `#nav-id`
var nav = ближайший (srcEl [0], el => el.id === 'nav-id')
// Здесь тег `

Теперь переменная nav устанавливается на ближайший элемент, соответствующий имени класса, идентификатору или имени тега. Это просто обычная старая ссылка на элемент DOM, с ней можно делать что угодно.

Этот метод невероятно легкий и универсальный! Это происходит из этого великого ответа SO.

Вот небольшая демонстрация.

Ближайшая демонстрация Pure JavaScript

JavaScript · Bootstrap v5.0

Индивидуальные или скомпилированные

Плагины могут быть включены по отдельности (используя индивидуальные js/dist/*.js ), или все сразу, используя bootstrap.js или уменьшенный bootstrap. min.js (не включайте оба).

Если вы используете сборщик (Webpack, Rollup…), вы можете использовать файлы /js/dist/*.js , которые готовы к UMD.

Использование Bootstrap в качестве модуля

Мы предоставляем версию Bootstrap, созданную как ESM ( bootstrap.esm.js и bootstrap.esm.min.js ), которая позволяет вам использовать Bootstrap в качестве модуля в вашем браузер, если ваши целевые браузеры поддерживают его.

 <тип сценария = "модуль">
  импортировать {Toast} из 'bootstrap.esm.min.js'
  Array.from(document.querySelectorAll('.toast'))
    .forEach(toastNode => новый Toast(toastNode))

 

Несовместимые плагины

Из-за ограничений браузера некоторые из наших плагинов, а именно плагины Dropdown, Tooltip и Popover, нельзя использовать в теге

Рубрики

• Css
• Html
• Js
• Адаптивный сайт
• Верстка
• Идеи
• С чего начать
• Советы
• Шаблоны
• Разное