Традиционно, объявление переменных было одной из необычных особенностей JavaScript. В большинстве C-подобных языков, создание переменной происходит в том месте, где она объявлена. Однако, в JavaScript это не так. Где Ваши переменные будут созданы, зависит от того, как Вы их объявили, и ECMAScript 6 предлагает возможности, что бы сделать контроль области видимости проще. В этой статье показано, почему классический var может ввести в заблуждение, вводится понятие блочной видимости в ECMAScript 6, а также приведены некоторые практические советы.

Строки в JavaScript были исторически функционально ограничены, не хватает возможностей, которые можно встретить в таких языках, как Python или Ruby. Шаблонные строки ES6 (доступно в Chrome 41+), вносят существенные изменения. Они представляют способ определения строк с помощью domain-specific languages (DSL), добавляя улучшения:

• Интерполяция строк
• Встроенные выражения
• Многострочный текст без хаков
• Форматирование строк
• Тегирование строк, для безопасного экранирования HTML, локализации и т.д.

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

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

Одна из наиболее распространенных задач, с которыми может встречаться фронтенд-разработчик, работа с DOM (Объектная Модель Документа). Обычно она заключается в определении расположения элемента DOM и затем управление им и/или его содержимым. Многие из нас использовали jQuery для этой задачи в течение последних семи или восьми лет, поскольку это - одна из основных задач, с которыми jQuery отлично справляется.

Для интернета семь лет это очень много. Вернемся в 2006 год, когда появился jQuery, Flash был очень популярен и интернет-приложения, разрабатывались на Flex или Silverlight, или даже Laszlo казалось, что они могли бы быть будущим веба. Кому нужен DOM, когда плагины были будущим веб-разработки.

С того момента, много изменилось. Браузер теперь поддерживает работу с DOM способами, которые не были возможны, когда jQuery только появился. Плюс, появились новые библиотеки, которые предлагают абсолютно другой подход к работе с DOM, чем тот, к которому мы привыкли. Итак, настало время спросить, нужен ли нам все еще jQuery для работы с DOM?

Собираем все вместе

• Модули содержат специфичные части функциональности вашего приложения. Они публикуют уведомления, информирующие приложение о том, что случилось что-то интересное. Это их главная забота. Как я поясню в FAQ, модули могут зависеть от различных вспомогательных методов для работы с DOM, но идеальным бы было отсутствие любых зависимостей от других компонентов системы. Модули не должны иметь отношение к тому:
  • какие объекты или модули подписаны на их сообщения,
  • где находятся эти объекты (на клиенте или на сервере),
  • какое количество объектов подписано на уведомления.

Паттерн «Медиатор»

Объяснить, что представляет собой паттерн «медиатор» достаточно просто на примере следующей аналогии — представьте себе контроль траффика в аэропорте: все решения о том, какие самолеты могут взлетать или садиться, принимает диспетчер. Для этого, все сообщения, исходящие от самолетов, поступают в башню управления, вместо того, чтобы пересылаться между самолетами напрямую. Такой централизованный контроллер — это и есть ключ к успеху нашей системы. Это и есть «медиатор».

Модули CommonJS

Возможно, вы что-то слышали о CommonJS за последние пару лет. CommonJS — это добровольная рабочая группа, которая проектирует, проектирует и стандартизирует различные JavaScript API. На сегодняшний день они ратифицировали стандарты для модулей и пакетов — CommonJS определяют простой API для написания модулей, которые могут быть использованы в браузере с помощью тега <script>, как с синхронной, так и с асинхронной загрузкой. Реализация паттерна «модуль» с помощью CommonJS выглядит очень просто, и я нахожу это уверенным шагом на пути к модульной системе, предложенной в ES Harmony (следующей версии JavaScript).

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

Паттерн «Модуль»

«Модуль» — это популярная реализация паттерна, инкапсулирующего приватную информацию, состояние и структуру, используя замыкания. Это позволяет оборачивать публичные и приватные методы и переменные в модули, и предотвращать их попадание в глобальный контекст, где они могут конфликтовать с интерфейсами других разработчиков. Паттерн «модуль» возвращает только публичную часть API, оставляя всё остальное доступным только внутри замыканий.

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

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

Мозговой штурм

Давайте немного подумаем, что мы хотим получить.

Для примера, у нас есть JavaScript-приложение, отвечающее за онлайн-пекарню. Одно из интересных нам сообщений может быть таким: «Партия из 42 батонов готова к доставке».

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

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

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

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

Давайте обсудим вашу существующую архитектуру

Я должен подчеркнуть значение этой разницы — я видел разработчиков, которые, сталкиваясь с большими приложениями, делали шаг назад и говорили: «Хорошо, у меня есть несколько идей, которые хорошо показали себя в моем предыдущем проекте среднего масштаба. Думаю, они точно сработают и для чего-то большего, не так ли?». Конечно, до какого-то момента это может быть так, но, пожалуйста, не принимайте это как должное — по большей части большие приложения имеют ряд достаточно серьезных проблем, с которыми нужно считаться. Ниже я приведу несколько доводов в пользу того, почему вам стоит уделить немного больше времени планированию архитектуры своего приложения, и чем вам это будет полезно в долгосрочной перспективе.

Перевод статьи Эдди Османи "Patterns For Large-Scale JavaScript Application Architecture"

В этой статье мы обсудим набор паттернов, который поможет вам в создании больших масштабируемых JavaScript-приложений. Материал статьи основан на моем одноименном докладе, впервые прочитанном на конференции «LondonJS», и вдохновленном предшествующей ему работой Николаса Закаса.

Вы можете скачать эту статью в форматах: epub, mobi, fb2 и pdf.

Оглавление

• Введение
• Что представляет собой «большое» JavaScript-приложение?
• Давайте обсудим вашу существующую архитектуру
• Думай о будущем
• Мозговой штурм
• Теория модулей
• Паттерн «Модуль»
• Литеральная нотация объектов
• Модули CommonJS
• Паттерн «Фасад»
• Паттерн «Медиатор»
• Использование фасада: абстракция ядра
• Использование медиатора: ядро приложения
• Собираем все вместе
• Развитие идеи медиатора: автоматическая регистрация событий
• Часто задаваемые вопросы
• Благодарности