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

Question

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

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

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

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

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

[БИБЛИОТЕКИ, УКАЗАННЫЕ, ПРОСТО ПРИМЕРЫ. ВОПРОС агностик к рамочным, библиотека и Серверный LANGUAGE]

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Вот немного доказательство концепции: Tagger Mediator POC

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

JQuery (1.9.1)

Mootools (1.4.5)

Прототип (1.7.1.0)

YUI (3.10.3)

Додзё (1.9.1)

внешн (3.4.0)

Zepto (1.0)

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

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

Answer 4

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

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

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

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

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

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

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

Редактировать: This 24ways article is a good primer на высоте встроенных функций 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; 
}); 

Answer 5

Скажи, что я разрабатываю компонент А, который имеет зависимость для underscore.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" 
    } 
    } 
} 
} 

Lifecycle callbacks интегрирован с CDN API, API checker, и on-demand script loader был бы другой вариант:

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 source code, samples, and documentation. See below for more info.

• XHTML™ Basic 1.1 - Second Edition

• X-Tag ★ Web Components

• coverage-ext

• How To Clean Up Your JavaScript Build With Tree Shaking

• Eliminating Unused CSS

• Analysing and minimising the size of client side bundle with webpack and source-map-explorer

• polyfill.io

Ссылки

• ECMA-290: ECMAScript Components Specification (PDF)

• Browser-based distributed evolutionary computation: performance and scaling behavior (ACM)

• Custom Elements Callback Queue

• Web Components Custom Elements Specification: Types of Custom Elements

• Lazy evaluation of CommonJS modules

• The Cost of Small Modules

• Yepnope load from CDN with Fallback (Example)

• Providing Local JS and CSS Resources for CDN Fallbacks · Edd Mann

• Plugin Pros and Cons

• Caja Playground

Answer 6

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

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

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

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

Answer 7

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

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

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