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

Эта статья должна быть обновлено. Соответствующее обсуждение можно найти на страница обсуждения. Обновите эту статью, чтобы отразить недавние события или новую доступную информацию. (Январь 2020)

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

Обзор

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

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

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

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

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

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

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

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

Отделение поведения от разметки

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

<ввод type ="текст" имя ="Дата" onchange ="validateDate ()" />

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

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

<ввод type ="текст" имя ="Дата" id ="Дата" />

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

окно.addEventListener("DOMContentLoaded", функция(мероприятие) {    документ.getElementById('Дата').addEventListener("изменять", validateDate);});

Пространства имён

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

вар org = org || {};если (тип org !== 'объект') {    бросать новый Ошибка("организация уже определена как не объект");}org.пример = org.пример || {};если (тип org.пример !== 'объект') {    бросать новый Ошибка("org.example уже определен как не объект");}

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

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

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

org.пример.Выделять.goBlue();вар час = org.пример.Выделять;час.goGreen();

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

Изящно деградируя

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

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

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

<а href="fullsize-image-001.png" учебный класс="ручная ссылка" заглавие="Нажмите для просмотра в полном размере">  <img src="image-001-thumb.png" учебный класс="большой палец" ширина="50" высота="50" альт="Изображение 1 показывает ... и т. Д."></а>

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

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

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

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

• Сценарии DOM, т.е. соблюдение W3C ДОМ модель событий и отказ от расширений, специфичных для браузера.
• Обнаружение возможностей, т.е. тестирование конкретной функциональности перед ее использованием.^[13] В частности, это рассматривается как противоположность обнаружению браузером.
• В более общем плане передовые практики JavaScript часто совпадают с практиками других языков программирования, таких как инкапсуляция и слои абстракции, избегание глобальные переменные, значимый соглашения об именах, использование соответствующих шаблоны проектирования, и систематический тестирование.

Смотрите также

• Изящная деградация
• Прогрессивное улучшение

Рекомендации