В этом посте мы надеемся изучить прошлое, текущее и будущее состояние процессов сборки в интерфейсных технологиях.
При работе с узлом использование модулей является обычным явлением, но я обнаружил, что не так много информации о том, как делать подобные вещи в браузере, поэтому я изучил его немного подробнее. Я хотел понять состояние транспиляции кода и объединения модулей, чтобы позволить текущим и более старым браузерам работать с написанным кодом, который использует модули или функции, которые они не могут поддерживать прямо сейчас.
Зачем нам вообще это делать?
Мы все еще живем в мире, где ни один браузер не поддерживает модули без необходимости каким-либо образом модифицировать код. Одной из первых библиотек, которая помогла решить эту проблему, была Browserify. Используя CommonJS, он позволял использовать модули в браузере, позволяя объединять все необходимые зависимости в один файл javascript. Обычно вы делаете шаг в процессе сборки (может быть, глотаете или хрюкаете). Это позволяет нам извлечь выгоду из инкапсуляции и зависимости, чего никогда не существовало в javascript в настоящей форме. Некоторое время назад я написал пост о раскрывающем шаблоне прототипа модуля, который интересен тем, что когда я его писал, я изучал то, что сейчас кажется предшественником модулей в его текущей форме.
Мы также выигрываем от следующего:
- Используйте такие языки, как последняя версия ECMAScript, typescript или coffescript, и будьте уверены, что старые браузеры будут поддерживать функции.
- Используйте Npm, который содержит более 475 000 общих пакетов, и их очень легко использовать в браузере, а также в приложениях Node.
Как бы мы загружали модули в прошлом?
Раньше мы ссылались на скрипт на странице и полагались на порядок загрузки. Хорошим примером этого является jQuery. Когда jQuery загружается, он добавляет $ к глобальной области видимости или окну. Это также означало, что если бы у вас была библиотека, зависящая от jQuery, вам нужно было бы убедиться, что библиотека была загружена впоследствии, или, как правило, вы должны были бы что-то сделать с загруженным документом, чтобы убедиться, что он будет работать. Если бы вы добавляли какой-то свой собственный код, вы бы спрятали его под пространством имен, например, window.MyNamespace, и надеялись, что он не будет конфликтовать ни с чем другим.
Как вещи будут загружаться в будущем
Мы сможем писать код на таких языках, как ES2015 › экспортировать объекты, используя общий формат модуля, такой как
export default class CraigsClass {
Functionality (){
alert("hello");
}
}Затем мы загрузим этот модуль в другой модуль, используя такой код, как
import CraigsClass from 'CraigsClass';
CraigsClass().Functionality();Преимущества этого:
- Порядок загрузки можно легко вывести из кода
- Пространства имен не требуются в окне
- Легкий доступ к модулям, размещенным в npm
- Легкий доступ к другим модулям в вашем коде
Настоящее
В его текущем состоянии запуск кода es2015 › с модулями в браузере означает, что код необходимо транспилировать. После просмотра выведенного кода он кажется очень сложным, например.
"use strict";Object.defineProperty(exports, "__esModule", { value: true });var _createClass = function () { function defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if ("value" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } } return function (Constructor, protoProps, staticProps) { if (protoProps) defineProperties(Constructor.prototype, protoProps); if (staticProps) defineProperties(Constructor, staticProps); return Constructor; }; }();var _CraigsClass = require("CraigsClass");var _CraigsClass2 = _interopRequireDefault(_CraigsClass);function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }(0, _CraigsClass2.default)().Functionality();var CraigsClass = function () { function CraigsClass() { _classCallCheck(this, CraigsClass); }_createClass(CraigsClass, [{ key: "Functionality", value: function Functionality() { alert("hello"); } }]);return CraigsClass; }();exports.default = CraigsClass;
Существует несколько определений модулей, таких как commonjs, umd, amd.
И вы можете связать свои активы, используя несколько разных сборщиков, таких как browserify, jspm, webpack и rollup, или вы можете определить свой собственный, используя gulp или grunt.
Вы можете транспилировать свой код с помощью одного из многих транспиляторов, таких как babel, coffeeScript или typescript.
Затем вы можете динамически загружать модули, используя другие библиотеки, такие как require.js или system.js.
Здесь вы можете найти отличную статью Стоимость транспиляции es2015-in-2016, в которой сравниваются различные комбинации вышеперечисленного.
Процессы сборки фронтенда
Существуют различные инструменты сборки для сборки/транспиляции/минификации/связки внешнего кода. Некоторые из наиболее популярных — это gulp и grunt, хотя вы можете использовать npm напрямую или работать с инструментом, который может делать все это, например с webpack.
Вы обнаружите, что конфигурация для создания внешнего кода кажется очень сложной, в основном потому, что существует так много разных способов сделать это, и каждый способ обрабатывает это по-разному! Существует много очень похожих функций, предоставляемых разными библиотеками, и много изобретений колеса, чтобы попытаться создать следующий лучший процесс сборки. Я не думаю, что есть однозначно лучший способ сделать это, но я думаю, что у каждого будет любимый после того, как он попробует другую технологию.
Подробнее о модулях
Модули автономны, и обновление модуля упрощается, если он отделен от других фрагментов кода. Модули можно использовать повторно, устраняя повторяющиеся фрагменты кода, тем самым экономя огромное количество времени. Чтобы использовать модули в настоящее время, нам нужно использовать загрузчик скриптов. Загрузка скриптов используется для того, чтобы сегодня мы могли использовать модульный JavaScript в приложениях, пока он не станет частью современных браузеров.
Существует ряд загрузчиков для обработки загрузки модулей, и при сборке для производства рекомендуется использовать инструменты оптимизации (например, оптимизатор RequireJS) для объединения скриптов.
AMD
Формат определения асинхронного модуля (AMD) используется для создания решения для загрузки модулей javascript в конце шрифта, которое разработчики могут использовать уже сегодня, а не ждать, пока браузеры поддержат модули. Формат модуля AMD позволяет асинхронно загружать зависимости. Это устраняет тесную связь между кодом и идентификацией модуля. AMD использует метод define для облегчения определения модуля и метод require для обработки загрузки зависимостей. AMD была создана, поскольку Commonjs также не подходит для браузеров. Это обеспечивает лучшее время запуска по сравнению с commonjs, и эти модули могут быть разных типов, таких как объекты, функции, конструкторы, строки, JSON и т. д.
Написано 10 марта 2018 г.
Первоначально опубликовано на https://craig.goddenpayne.co.uk/javascript-bundling/
