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

Как кто-то, кто пытался найти способ помочь разработчикам контента, развивает и поддерживает большие веб-сайты, создавая (HTML) компоненты в течение многих лет, я очень рад видеть, что веб-компоненты набирают силу в w3c, google и mozilla. Но мне кажется, что нет никаких мер против разрастания библиотеки JavaScript в спецификациях.

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

Текущее решение - стандартизировать опционную клиентскую инфраструктуру для всего веб-сайта во всем мире. Это сложно, если вы вложили значительные ресурсы в разные серверные среды, такие как LifeRay (java), EpiServer (.net), Django (python) и т.д., Каждый из которых имеет предпочтительные клиентские библиотеки.

Я вижу веб-компоненты как средние, чтобы отделить серверные структуры от клиентского кода, но упущение обработки зависимостей на стороне клиента вызывает беспокойство.

Является ли это спецификацией, и я пропустил ее, или существует стратегия для устранения этой проблемы, о которой я не знаю?

[ОТОБРАЖАЕМЫЕ БИБЛИОТЕКИ ПРОСТО ПРИМЕРЫ. ВОПРОС АГНОСТИЧЕСКИ В РАМКАХ, БИБЛИОТЕКЕ И СЕРВЕРНО-БОКОВОМ ЯЗЫКЕ]

UPDATE Спасибо всем за ответ. Я удивлен, что никто не упоминает X-Tag Mozilla или Google Polymer, который в последнее время был всего лишь шумихой. Я полностью покупаю идею теневого DOM, облачных стилей, пользовательских элементов и т.д., Но нигде я не вижу упоминаний о том, как обращаться с зависимостями JavaScript. Поскольку @Daniel-Baulig правильно пишет HTML Imports, не упоминает JavaScript вообще. Я признаю, что этот вопрос почти невозможно ответить. Тем не менее, я думаю, что @Daniel-Bailig подошел ближе, когда он упомянул модули ES6. Я лично считаю, что мы найдем устойчивое решение где-то между модулями ES6 и require.js.

Ответ 1

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

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

Возможно, Модули ES6 предоставляют помощь в этом отношении, но опять же они в настоящее время также не предоставляют никаких механизмов управления версиями.

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

Кроме того, если вы заинтересованы в разработке независимых компонентов для Интернета уже сегодня, вам может понадобиться рассмотреть React library

Ответ 2

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

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

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

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

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

например. медиаторы включены для:

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)

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

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

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

Изменить: Эта статья 24-го уровня является хорошим праймером о росте встроенных функций 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;
});

Ответ 6

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

В 1999 году появилась стандартная спецификация ECMA (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"
     }
   }
 }
}

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

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

Подмножество HTML, как в следующих проектах, - это решение, которое неоднократно проверялось:

Ссылки

Ответ 7

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

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

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

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

Ответ 8

ИМХО описанная вами проблема всегда существует во внешнем интерфейсе и не имеет прямого отношения к веб-компонентам, но веб-компоненты делают это еще хуже.

Скажем, если вы полагаетесь на компоненты A и B, которые все полагаются на lodash, если только A и B не установят lodash равноправными зависимостями (что делает их похожими на плагины, как большинство плагинов jquery), то вы можете включить одну копию lodash, в противном случае, А и Б предназначены для вас как черный ящик. Хотя компоновщики могут выполнять некоторую обработку после сборки, например, встряхивание дерева/удаление мертвого кода, чтобы помочь смягчить это, но это никогда не сможет работать на 100%, например, A и B полагаются на две разные версии lodash.

Почему веб-компоненты делают это еще хуже? цель WC - обеспечить независимый от фреймворка способ повторного использования компонентов пользовательского интерфейса, скажем, если я использую vue и кучу компонентов vue, мои js-пакеты заканчиваются этими компонентами, и единственная среда выполнения vue, потому что vue является равноправным депо в этих компонентах, Теперь, если я использую WC и несколько компонентов WC, я, скорее всего, получу js большего размера. Например, можно создать простой компонент WC с подсветкой с помощью простой кнопки, затем создать проект и посмотреть, насколько значительно больше комплект js. Некоторые фреймворки могут использовать другой подход, например vue, но при этом вы должны добавить vue как внешнюю фреймворк для запуска WC на основе vue, что не сэкономит вам ни одного байта, если вы переключите vue на WC. Кроме того, совместное использование стилей является еще одной проблемой в WC с точки зрения уменьшения размера пакета.

Моя компания использует bootstrap и реагирует, наше приложение состоит из 1 начальной загрузки, 1 реакции и множества внешних компонентов реакции, которая уже составляет 3,5 МБ/сс, я сомневаюсь, что мы можем сделать то же самое в WC в 3,5 МБ.