Ненавязчивый JavaScript

редактировать

Ненавязчивый JavaScript - это общий подход к использованию JavaScript на веб-страницах. Хотя этот термин формально не определен, его основные принципы обычно понимаются как включающие разделение функциональности («уровень поведения») от структуры / содержания и веб-страницы. и прогрессивное улучшение для поддержки пользовательских агентов, которые могут не поддерживать определенные функции JavaScript, и пользователей, отключивших JavaScript.

Содержание
  • 1 Обзор
  • 2 Отделение поведения от разметки
  • 3 Пространства имен
  • 4 Изящная деградация
  • 5 Лучшие практики
  • 6 См. Также
  • 7 Ссылки
Обзор

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

Концепция «ненавязчивости» по отношению к программированию на JavaScript была придумана в 2002 году Стюартом Лэнгриджем в статье «Ненавязчивый DHTML и сила неупорядоченных списков». В статье Лэнгридж доказывал, что весь код JavaScript, включая обработчики событий, должен находиться вне HTML. С тех пор Стюарт Лэнгридж развил эту мысль в формате книги и статьи.

Другие авторы пытались уточнить и определить основные элементы ненавязчивости. В книге Дэвида Флэнагана «JavaScript: окончательное руководство» говорится, что, хотя конкретной формулы нет, существуют три основные цели:

  • Отделить JavaScript от разметки HTML, а также сохранить независимость модулей JavaScript от других модулей.
  • Ненавязчивый JavaScript должен постепенно ухудшаться - весь контент должен быть доступен без успешного выполнения всего или какого-либо JavaScript.
  • Ненавязчивый JavaScript не должен ухудшать доступность HTML, а в идеале должен улучшать его, независимо от того, есть ли у пользователя личные инвалиды или используют необычный или необычно настроенный браузер.

Проект веб-стандартов описал четыре преимущества ненавязчивого написания сценариев DOM в своем манифесте JavaScript.

  1. Удобство использования : ненавязчивый сценарий DOM не привлекает внимание пользователя - посетители используют его, не задумываясь об этом.
  2. Изящная деградация : ненавязчивые сценарии DOM никогда не генерируют сообщения об ошибках ни в одном браузере, даже когда они терпят неудачу. Если функции не могут быть представлены должным образом, они незаметно исчезают.
  3. Доступность : Если какой-либо сценарий не работает, страница по-прежнему доставляет свои основные функции и информацию через разметку, таблицы стилей и / или сценарии на стороне сервера.
  4. Разделение : В интересах других и будущих веб-разработчиков весь код JavaScript поддерживается отдельно, не затрагивая другие файлы сценария, разметки или кода.

На Парижской веб-конференции в 2007 году Кристиан Хейльманн определил семь правил ненавязчивого JavaScript.

  1. Не делайте никаких предположений: Защитные методы программирования должны учитывать те возможности, которые могут не выполняться JavaScript, браузер может не поддерживать ожидаемые методы, HTML может быть изменен могут использоваться неожиданные устройства ввода, а другие сценарии могут либо отсутствовать, либо вторгаться в глобальное пространство имен.
  2. Найдите свои ловушки и связи, такие как идентификаторы и другие аспекты ожидаемого HTML.
  3. Оставить обход отдельного объекта DOM s экспертам, например, обработчику CSS, встроенному в браузер, где это возможно.
  4. Поймите браузеры и пользователей, в частности, как они терпят неудачу, какие предположения они делают, а также необычные конфигурации или способы использования.
  5. Разберитесь в событиях, в том числе в том, как они «всплывают», и в особенностях объекта Event, который передается большинству обработчиков событий.
  6. Хорошо играйте с другими скриптами, избегая глобальные функции и имена переменных.
  7. Работайте для следующего разработчика, используя понятные имена переменных и функций, создавая логичный и читаемый код, делая зависимости очевидными и комментируя любой код, который все еще может сбивать с толку.
Разделение поведения из разметки

Традиционно JavaScript часто размещался встроенным вместе с разметкой документа HTML. Например, следующий типичный способ зарегистрировать обработчик событий JavaScript в HTML:

Целью разметки HTML является описание структуры документа, а не его программного поведения. Их сочетание может негативно повлиять на ремонтопригодность сайта, например сочетание содержимого и представления. Поведение JavaScript, созданное и указанное в HTML, может быть сложнее в использовании и обслуживании, например, при настройке обработчиков для нескольких событий в одном элементе, при настройке одного и того же обработчика событий для нескольких элементов или при использовании делегирования событий.

Ненавязчивое решение - зарегистрировать необходимые обработчики событий программно, а не встроенно. Вместо того, чтобы явно добавлять атрибут onchange, как указано выше, соответствующие элементы просто идентифицируются, например, с помощью class, idили каким-либо другим способом в разметке:

Сценарий, который запускается при первой загрузке страницы в браузер, затем может искать каждый соответствующий элемент и настраивать его соответствующим образом:

window.addEventListener ("DOMContentLoaded", function (event) {document.getElementById ('date'). addEventListener ( "изменить", validateDate);});
Пространства имен

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

var org = org || {}; if (typeof org! == 'object') {throw new Error ("организация уже определена как не-объектная"); } org.example = org.example || {}; if (typeof org.example! == 'object') {throw new Error ("org.example уже определен как не-объект"); }

Хотя переменные, функции и объекты всех видов могут быть дополнительно определены в таких объектах пространства имен, обычно рекомендуется использовать замыкания внутри пространства имен для дальнейшего изолирования того, что станет частные переменные и функции, а также для экспорта того, что будет публичным интерфейсом каждого модуля функциональности. За приведенным выше кодом может следовать следующий код, который использует IIFE для закрытия:

org.example.Highlight = (function () {// Определение частных данных и функций var highlightId = 'x'; function setHighlight (color) {document.getElementById (highlightId).style.color = color;} // Возвращаем общедоступные указатели на функции или свойства, // которые должны быть общедоступными. return {goGreen: function () {setHighlight ('зеленый');}, goBlue: function () {setHighlight ('синий');}}} ()); // Конец закрытия

Из любого другого модуля эти общедоступные методы могут быть вызваны любым из следующих способов:

org.example.Highlight.goBlue (); var h = org.example.Highlight; h.goGreen ();

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

Изящная деградация

Написание прослушивателя событий, который обнаруживает загрузку HTML-страницы и затем добавляет соответствующие прослушиватели к другим событиям на странице, а также другое поведение по мере необходимости может решить проблему. отделения функциональности JavaScript от разметки HTML. Использование клиентских библиотек JavaScript, таких как jQuery, MooTools или Prototype, может упростить этот процесс и помочь гарантировать, что детали реализации конкретного браузера и версии браузера скрыто и обслуживается. Сохранение большей части JavaScript в пространстве имен по умолчанию помогает сделать его максимально ненавязчивым в этом смысле. Еще один критерий ненавязчивого JavaScript, который часто упоминается, заключается в том, чтобы гарантировать, что добавленное поведение постепенно ухудшается в тех браузерах с неожиданными конфигурациями, а также в тех, в которых пользователь мог вообще отключить JavaScript.

Это требование является основным принципом веб-доступность, чтобы гарантировать, что веб-сайты с расширенным JavaScript могут использоваться не только людьми с разными способностями и ограниченными возможностями, но и чтобы все пользователи - независимо от их вычислительной платформы - получали равный доступ ко всей информации и функциям сайта. Иногда для этого требуется дополнительная работа, но во многих странах доступность Интернета не является обязательной. Например, в Соединенном Королевстве Закон о равенстве 2010, хотя он прямо не касается доступности веб-сайтов, запрещает дискриминацию людей с ограниченными возможностями и распространяется на всех, кто предоставляет какие-либо услуги в государственном, частном и частном секторах. добровольные сектора. Хотя можно приложить немало усилий для разработки и реализации удобного пользовательского интерфейса на стороне клиента в ненавязчивом JavaScript, он не останется ненавязчивым для пользователя без сценариев на стороне клиента, если они обнаружат, что не могут получить доступ к опубликованным Информация. Для достижения этой цели часто необходимо реализовать эквивалентную, хотя и более громоздкую, серверную функциональность, которая будет доступна без использования JavaScript вообще.

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

Изображение 1 показывает... и т. Д.  

Это будет работать, как и без JavaScript. В этом случае ненавязчивый JavaScript во время загрузки страницы может найти все элементы a, которые имеют класс manual-link, и удалить их со страницы DOM. Затем он может найти все изображения класса thumbи прикрепить обработчик событий onmouseoverили onclick, который указан в строке для обеспечения плавного поведения. Например, при вызове обработчик событий может отправить запрос Ajax на сервер для полноразмерного изображения, а затем добавить divв DOM страницы, вызывая существующий CSS, чтобы он отображался в перед существующим контентом, который сам может стать частично серым. Для divпотребуется кнопка закрытия, возможно, визуальный «счетчик», чтобы показать, что данные загружаются, и т. Д. Наконец, когда поступают данные Ajax, обработчик скрывает счетчик и вставляет полноразмерное изображение в новый divдля отображения.

Таким образом, все клиентские функции зависят от одной и той же функции JavaScript. Если эта функция завершается успешно, она начинается с удаления базового ручного поведения и продолжается добавлением сценариев на стороне клиента. Если сценарий не работает по какой-либо причине, ручное поведение остается на месте и остается работоспособным.

Лучшие практики

Хотя суть ненавязчивого JavaScript - это концепция добавленного отдельного уровня поведения, его сторонники обычно придерживаются ряда связанных принципов, таких как:

См. также
Ссылки
Последняя правка сделана 2021-06-20 14:24:37
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте