JS (MODULES, WEBPACK)

IIFE Modules
Immediately Invoked Function Expression

Window

………………. App

(function)()
2
 ТОГДА
История концепции модулей как единиц компиляции восходит к языкам
ФортранII и Кобол, то есть, к концу 1950-х годов.

Но основные прин­ци­пы модульного программирования сфор­му­ли­ро­вал в 1972

Д. Пар­нас (Ка­на­да) – спе­циа­лист в об­лас­ти раз­ра­бот­ки про­грамм­но­го обес­пе­че­
ния, и они были следующими:
• для на­пи­са­ния од­но­го мо­ду­ля долж­но быть дос­та­точ­но ми­нимум зна­ний об ис­
ход­ном ко­де других мо­ду­лей (т. н. прин­цип утаи­ва­ния);
• из­ме­не­ние мо­ду­ля и его по­втор­ная транс­ля­ция не долж­ны при­во­дить к из­ме­не­
ни­ям и по­втор­ной транс­ля­ции др. мо­ду­лей.

В кон. 1970-х гг. эти прин­ци­пы бы­ли реа­ли­зо­ва­ны швейцарским учё­ным в об­лас­ти
ин­фор­ма­ти­ки Н. Вир­том в ЯП мо­ду­ла-2, ко­то­рый был ос­но­ван на раз­ра­бо­тан­ных
им же языках программирования Pascal ­и Modula.
В 1990-х гг. стан­дар­том модульного программирования ста­ло объектно-
ориентированное программирование, па­ра­диг­ма ко­то­ро­го под­дер­жи­ва­ет­ся
языками C++, Java, современными версиями Pascal, Basic и мн. др.

До стандартизации существовало несколько библиотеки для динамической

подгрузки модулей, например
• AMD – одна из самых старых модульных систем, изначально реализована
библиотекой [Link].
• CommonJS – модульная система, созданная для сервера [Link].
• UMD – ещё одна модульная система, предлагается как универсальная,
совместима с AMD и CommonJS.
3
 СЕЙЧАС
С начала 21 века модульное программирование при­ме­ня­ет­ся при раз­
ра­бот­ке всех дос­та­точ­но слож­ных про­грамм.

Система модулей на уровне языка появилась в стандарте JavaScript в

2015 году и постепенно эволюционировала. На данный момент она
поддерживается большинством браузеров и [Link]

Модуль – это просто файл. Один скрипт – это один модуль.

Модули могут загружать друг друга и использовать

директивы export и import, чтобы обмениваться функциональностью,
вызывать функции одного модуля из другого:
Export отмечает переменные и функции, которые должны быть
доступны вне текущего модуля.
Import позволяет импортировать функциональность из других
модулей.

4
 ОСОБЕННОСТИ
1. В модулях всегда используется режим use strict. Строгий режим
помогает в паре моментов: Он ловит некоторые распространенные ошибки
кодирования, выбрасывая исключения. Он предотвращает или выдает ошибки,
когда выполняются относительно "unsafe" действия (например, получение
доступа к глобальному объекту). Он отключает функции, которые сбивают с
толку или плохо продуманы.
2. Своя область видимости переменных. Каждый модуль имеет свою
собственную область видимости. Другими словами, переменные и функции,
объявленные в модуле, не видны в других скриптах. Если мы хотим какую-то
переменную сделать глобальной, мы должны присвоить ее window
3. Код в модуле выполняется только один раз при экспорте, после чего
экспортируемая функциональность передаётся всем импортёрам. Т.е. если
мы экспортируем какой-то объект, то именно этот один объект получат все
импортеры.
4. В модуле не определен “this”. И если в немодульных скриптах он на
высшем уровне является window, то здесь – undefined
5. Модули всегда являются отложенными (defer), т.е. загрузка внешних
модулей не блокирует обработку HTML. Модули, даже если загрузились быстро,
ожидают полной загрузки HTML документа, и только затем выполняются.
Сохраняется относительный порядок скриптов: скрипты, которые идут раньше в
документе, выполняются раньше.
6. Не допускаются “голые” модули. В браузере import должен содержать
относительный или абсолютный путь к модулю.
5
 EXPORT

Экспорт может идти отдельно от объявления, причем как до, так и

после самого объявления.
const a = 10;
export a;
6
 EXPORT
Мы можем использовать AS, чтобы экспортировать под другим именем.

Экспорт может быть дефолтным. Но таким образом мы можем

экспортировать только что-то одно: переменную, функцию, класс.
Дефолтный метод в модуле может быть только один. При импорте нет
необходимости ставить {}, а также мы можем обозвать полученные
данные как хотим. Обычно его используют при экспорте модулей или
компонентов.

Технически в одном модуле может быть как экспорт по умолчанию,

так и именованные экспорты, но на практике обычно их не
смешивают. То есть, в модуле находятся либо именованные
экспорты, либо один экспорт по умолчанию.
7
 IMPORT
Обычно мы располагаем список того, что хотим импортировать, в
фигурных скобках import {...} с перечислением через запятую, или в
виде объекта, используя import * as <obj>

8
 ИНСТРУМЕНТЫ
СБОРКИ
Обычно, мы объединяем модули вместе, используя специальный
инструмент, например Webpack и после выкладываем код на рабочий
сервер.
Сборщик делает следующее:
1.Берёт «основной» модуль, который мы собираемся поместить в <script
type="module"> в HTML.
2.Анализирует зависимости (импорты, импорты импортов и так далее)
3.Собирает один файл со всеми модулями (или несколько файлов, это можно
настроить), перезаписывает встроенный import функцией импорта от сборщика,
чтобы всё работало. «Специальные» типы модулей, такие как HTML/CSS тоже
поддерживаются.
4.В процессе могут происходить и другие трансформации и оптимизации кода:
•Недостижимый код удаляется.
•Неиспользуемые экспорты удаляются («tree-shaking»).
•Специфические операторы для разработки, такие как console и debugger,
удаляются.
•Современный синтаксис JavaScript также может быть трансформирован в
предыдущий стандарт, с похожей функциональностью, например, с
помощью Babel.
•Полученный файл можно минимизировать (удалить пробелы, заменить
названия переменных на более короткие и т.д.).

9
Coffee Look & Feel

10
Employees Look & Feel

11