Как разбухание библиотеки JavaScript смягчается с помощью веб-компонентов?

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

или, скорее, "потенциальное" решение, на которое я смотрю, - это создать тип рамки посредника.

в основная идея состоит в том, чтобы кодировать "против" посредника (никогда не получая доступ/используя библиотеку js напрямую, но используя ее через посредника), тем самым по существу делая код агностическим (отделенным от его "родительской" библиотеки) и включая реализацию посредничества под ним.

Это не будет решать мою / нашу непосредственную проблему или раздувание, но любой веб-компонент, который я пишу будет возможность запускать cross framework.

вот небольшое доказательство концепции: Посредник Таггер POC

Е. Г. посредники включены:

JQuery (1.9.1)

Mootools (1.4.5)

прототип (1.7.1.0)

YUI (3.10.3)

Dojo (1.9.1)

Ext (3.4.0)

Zepto (1.0)

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

Я думаю, это до вас, чтобы установить свои собственные стандарты;)

У меня были подобные опасения по поводу веб-компонентов, но затем я начал работать с сторонними компонентами React. У них есть те же проблемы, что и у всех их собственных зависимостей. Но хуже того, поскольку React не любит жить с другими версиями React, компоненты React должны отображать React как одноранговую зависимость. Это означает, что вы вынуждены использовать ту же версию React, что и сторонние компоненты.

Итак, мой вывод заключается в том, что это на самом деле характеристика веб-компонентов! Каждый пользовательский элемент может иметь свои собственные зависимости, полностью независимым от остальной части вашего приложения. Я считаю, что сторонние компоненты являются основным вариантом использования веб-компонентов; где потребитель хочет иметь возможность использовать компонент с как можно меньшим трением. Конечно, будет какой-то дубликат кода, но потребителю компонентов не нужно знать или заботиться. Я думаю, что авторы компонентов будут заниматься этим, используя меньшие модули в их компонентах. Например, вместо использования React они могут использовать что-то вроде Snabbdom.

Если вы создаете целое приложение из веб-компонентов, которые вы контролируете, вы все равно можете использовать инструмент связывания, такой как Browserify или WebPack для управления зависимостями. Это позволит вам переопределить некоторые модули, чтобы вы даже могли заставить сторонние компоненты использовать те же версии, что и остальная часть вашего приложения (см.:https://www.npmjs.com/package/aliasify). Это может сломать некоторые модули, но это жизнь.

Я никогда не слышал о стандартизации фреймворков javascript. Однако с HTML5 некоторые части, которые раньше нуждались в JavaScript-фреймворках в более ранних версиях HTML, теперь были добавлены в качестве стандартной функции в HTML5 (например, тег <canvas>, округлые границы, тени, ...), что является первым шагом в решении того, что вы упомянули.

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

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

думаю с подъемом npm такие библиотеки становятся все менее и менее актуально. Lo-Dash является хорошим примером этого, потому что его функции выпускаются на npm как автономные модули, но у вас также есть такие вещи, как шипеть, механизм селектора CSS, который использует jQuery. Если вы посмотрите достаточно трудно, вы можете найти множество плагинов, которые пишутся без jQuery как зависимость, или он находится в дорожной карте проекта для удаления зависимостей, или кто-то уже разветвил проект, чтобы удалить его зависимость от другая библиотека. Например, экзоскелет, полностью подчеркивание & jQuery бесплатная версия магистрали.

Я не думаю, что мы увидим другую популярную служебную библиотеку, такую как jQuery или underscore; с npm мы можем просто выбрать модули, которые мы хотим, и проекты fork, которые зависят от этих больших библиотек, чтобы переписать их, используя только модули, которые они need, или полностью бесплатная версия зависимости.

С AMD и помощью RequireJS, это уже реальность. Вы можете определить некоторые зависимости исходного кода; вместо ссылки на монолитные библиотеки в коде вы можете указать, что этот компонент нужен только, например microajax вместо всей библиотеки jQuery:

define(['microajax'], function(microAjax) {
    microAjax("/resource/url", function (res) {
      alert (res);
    });
});

Проверьте сайт microjs для более вспомогательных библиотек, таких как эта.

что касается веб-компонентов, я надеюсь, что авторы этих пишут свои компоненты таким образом, чтобы они не требовали массивных библиотек, таких как jQuery, которые могут делать все. И если они это сделают, я также надеюсь, что смогу развести их и обрезать все ненужные части самостоятельно. :-)

Edit:эта статья 24ways является хорошим праймером на подъеме собственных функций JS, которые в конечном итоге заменят jQuery. Стоит отметить, что jQuery был написан в то время, когда реализации JavaScript были дико разными; но как стандартизация поднялся и API стали более последовательными, потребность в оболочке вокруг собственной функциональности несколько уменьшилась. Например, теперь у нас есть querySelectorAll:

// jQuery
$('.counter').each(function (index) {
  $(this).text(index + 1);
});

// Vanilla JavaScript
var counters = document.querySelectorAll('.counter');
[].slice.call(counters).forEach(function (elem, index) {
  elem.textContent = index + 1;
});

мы просто пытаемся сохранить наш веб-компонент javascript до минимума, сохраняя их след очень низким. Поэтому вместо использования подчеркивания для чего бы то ни было, мы просто используем собственные эквиваленты ES6 (учитывая существующие веб-компоненты использования, это не так много).

затем мы упаковываем наши веб-компоненты с одним html-файлом, одним css-файлом и одним JS-файлом. На самом деле они могут состоять из нескольких файлов, но наш процесс сборки позаботится об этом. Наш файл javascript в комплекте с Browserify, что позволяет нам использовать модули npm, в то время как они красиво упакованы в нашем веб-приложении.

Это предлагает действительно хорошие крошечные, но blackbloxed веб-компоненты, которые могут делиться общими модулями без каких-либо конфликтов и без необходимости беспокоиться о накладных расходах AMD, просто простые commonjs для всего.

Если нам когда-либо понадобится связать тяжелую библиотеку с несколькими компонентами, мы либо сделаем эту библиотеку внешней и передадим ее, оставив включение вверх по приложению (вот как вы должны это сделать с помощью backbone.Яш, из-за позвоночника.js, используя instanceof вместо ввода утки, делая несколько магистралей.экземпляры js разговаривают друг с другом невозможно), или веб-компоненты связывают его с помощью браузера cdn-сервера, такого как wzrd.В-однако, гораздо лучше для родительского веб-приложения обрабатывать большие deps, как если бы веб-компоненты использовали разные cdns, тогда у вас есть проблема.

скажем, что я разрабатываю компонент A, который имеет зависимость для подчеркивания.js и хотите использовать компоненты B и C, которые имеют зависимости от lodash.с JS версии 1.*, п. Я не вижу никакого способа помечать зависимости и версии библиотек.

есть старая спецификация ECMA от 1999 (ECMA-290), которая указала механизм компонента, который включал элементы и атрибуты для зависимостей и версий библиотеки:

<component
name="com.mycompany.selectnav"
displayname="SelectNav"
src="selectnav.js"
env="client"
hint="Navigational Select List"
version="1.0"
needsform="yes">
</component>

для зависимостей, используйте customizer элемент. Для управления версиями, используйте meta элемент. Например:

<customizer type="ecmascript" url="http://com.com/foo">
  <meta name="version" value="1.1b"/>
</customizer>

кодировка JSON для современной реализации будет выглядеть так:

{
"component":
 {
 "name":"com.mycompany.selectnav",
 "displayname":"SelectNav",
 "src":"selectnav.js",
 "env":"client",
 "hint":"Navigational Select List",
 "version":"1.0",
 "needsform":"yes",
 "customizer":
   {
   "type":"ecmascript",
   "url":"http://com.com/foo",
   "meta":
     {
     "name":"version",
     "value":"1.1b"
     }
   }
 }
}

обратный вызов жизненного цикла интегрирован с CDN API, an API checker и загрузчик скриптов по требованию был бы другой вариант:

createdCallback => check API URL => createElement for dependent script tags => onload event for dependent script tags => appendChild for dependent script tags

подстановка HTML, как в следующих проектах, является решением, которое было опробовано множество раз:

• GitHub-ampproject / amphtml: исходный код AMP HTML, образцы и документация. См. ниже для получения дополнительной информации.

• XHTML™ Basic 1.1-второе издание

• X-Tag ★ Веб-Компоненты

• покрытие-ext

• Как Очистить Вашу Сборку JavaScript С Помощью Дерева Тряска

• устранение неиспользуемого CSS

• анализ и минимизация размера клиентского пакета с webpack и source-map-explorer

• полифилл.io

ссылки

• ECMA-290: компоненты ECMAScript Спецификация (PDF)

• браузерные распределенные эволюционные вычисления: поведение производительности и масштабирования (ACM)

• Очередь Обратного Вызова Пользовательских Элементов

• веб-компоненты пользовательские элементы спецификация: типы пользовательских элементов

• ленивая оценка модулей CommonJS

• Стоимость малых модулей

• загрузка Yepnope из CDN с резервным вариантом (пример)

• предоставление локальных ресурсов JS и CSS для резервных CDN * Edd Mann

• плюсы и минусы плагина

• Caja Площадка