Comments 50
Небольшая ремарка по поводу полифиллов и работы всего этого в IE.
Дело в том, что поведение shadow dom сильно отличается от того, что было в браузерах до этого. Поэтому легко заполифиллить это не получится. Указанный в статье полифилл делает много чего:
- Полностью переписывает систему всплытия событий
- Переписывает операции с DOM-узлами: appendChild, removeChild, querySelector и т.д.
- innerHTML тоже досталось
Насколько производительно такое переписывание нативного DOM API на JS — решайте сами.
Из своего опыта скажу, что эта абстракция еще и течет. Соседняя со мной команда, которая пилит проект на Polymer, столкнулась с тем, что event.target может быть undefined. В Chrome работает как надо, в IE без полифиллов тоже, а вот IE+полифиллы — всё ломается.
Нативные веб-компоненты еще можно как-то рассматривать как полезную и перспективную технологию, но если нужна полноценная поддержка IE, то нужно тщательно подумать. Подводные камни неидеальности полифиллов всплывут внезапно.
Если нужна поддержка IE — да, нужно подумать. Не всем она нужна просто, нужен анализ аудитории. Для моих приложений, доля пользователей с IE — изчезающе мизерная. Я откровенно признаю, что я на них забил, и не страдаю от этого никак: денег они не приносят.
доля пользователей с IE — изчезающе мизерная
Секция в статье называется "Хорошо, а что делать с остальными ~20% пользователей?". Одна пятая часть – это слишком много чтобы называться "изчезающе мизерной". Какое-то противоречие.
~20% — это не пользователи IE. Точнее не только они. IE11 используют 2.66% от общего глобального трафика, и львиная доля это — китайцы и боты. Как я и говорил, для принятия обоснованного решения в конкретном случае — нужен анализ аудитории в рамках текущих бизнес-задач. Для кого-то игнор IE может быть неприемлемым, для кого-то наоборот. В целом же, сегментация веб-платформы на уровне поддержки стандартов — это ее главная болезнь, которую нужно лечить. И часть этого лечения заключается в принципиальной позиции разработчиков по отказу поддержки всякой некрофилии.
Сборка с полифиллами сильно отличается от нативной имплементации, поэтому нужно ожидать дополнительных затрат по времени на борьбу с багами там, либо просто забить на 20% пользователей (что тоже возможно).
В Edge полифилы стабильно работают, тесты проходят. Времени больше уходит на другое: Edge, к примеру, не поддерживает свойство object-fit для canvas, подобные нюансы постоянно всплывают и требуют внимания. Но не скажу что проблемы с полифилами занимают в этом какую-либо значительную часть. В конце концов, тестирование этих решений происходит на нескольких уровнях: как самими экосистемными разработчиками, так и разработчиками "на местах". Ну и пользователей у того-же ю-туба вполне достаточно чтобы ловить основные баги.
Дополню: Opera Mini, к примеру — 2.47%, это сравнимо с IE, однако этот браузер — в вечной красной зоне и не поддерживает вообще ничего. Он существует для просмотра простых HTML-страничек и никак не является платформой для приложений. Что теперь, не писать приложения для веб из-за этого?
Еще из дискуссии к прошлой статье остался неотвеченный вопрос, как использовать веб-компоненты без Polymer, чтобы получался компактный код без лишних повторений.
P.S. в любом случае спасибо автору за статью, за продвижение интересных идей, которые можно обсудить.
React, Vue, Angular, etc. предлагают не только и не столько собственную реализацию решений, на которых основаны web components, сколько модель работы с данными.
Писать собственные реализации flux-хранилищ, описывать собственную реактивную модель — это либо очередной велосипед, либо опять-таки куча зависимостей, от которых якобы нас спасут web components…
А обвинять людей в использовании чего-то модного и нежелании знать ничего другого — это, знаете ли, так себе. Мы в массе своей создаём продукты для бизнеса, условия диктует рынок, а не мы…
А вы, видимо, в очередной раз оказались неспособны прочитать статью полностью. Вам никто не мешает использовать тот-же Redux в сочетании с веб-компонентами. В pwa-starter-kit, к примеру, он используется по умолчанию. Веб-компоненты берут на себя вполне определенный ряд задач, как вы будете решать остальные — остается на ваше усмотрение. Равно как и в случае с React, Vue, Angular, etc. Велосипед — это лишь один из возможных подходов, который нравится лично мне, по вполне конкретным причинам. Я их привожу постоянно и не вижу в этом ничего дурного. Все популярные решения, в конце концов, начинали как велосипеды. А рынок диктует, да. Он диктует требования к надежности, скорости разработки, скорости загрузки, стоимости поддержки и т. д. И все, о чем я пишу, это ответы на эти требования.
React (react + react-dom) сам по себе тянет за собой 5(!) зависимостей:
- loose-envify
- js-tokens
- object-assign
- prop-types
- schedule
Вы вот серьёзно? Непомерного количества?
И так у вас везде.
Вы уповаете на Polymer. Ок, вопросов нет, забавная игрушка с возможной перспективой. Но скажите, почему Google всё ещё не отказался от Angular, если использование Web Components настолько быстрее/лучше/красивей/зеленее?
Почему вы такие вопросы в статье обходите стороной? Где объективизм?
Вы говорите, что все решения начинались как велосипеды, но это больше похоже на слова зелёного джуна (которым вы-то, скорее всего, не являетесь, что ещё больше пугает), неспособного разобраться в теме, не пришедшего к пониманию того, что все сегодняшние популярные решения — это старые (читай проверенные временем) решения «портированные» из других языков, парадигм и т.д.
Вы говорите, что рынок должен пойти за Web Components, потому как они отвечают его требованиям «к надежности, скорости разработки, скорости загрузки, стоимости поддержки и т. д».
Возможно! Но чтоб рынок поверил в это, нужно сначала рынку показать, что это решение используется и поддерживается крупными игроками (надежность), что на рынке есть достаточное количество специалистов, работавших с этим решением (скорость разработки и стоимость поддержки), что есть реальные исследования, говорящие о том, что Web Components быстрее грузятся, нежели популярные сегодня решения, честные исследования, учитывающие кэширования популярных версий из cdn, например, учитывающих минификацию сорсов.
Я вас уверяю, ни по одному из этих пунктов Web Components не выиграют. И именно поэтому они на сегодняшний день не популярны.
Вы так защищаете Web Components, как будто на них кто-то нападает, как будто кто-то спорит с тем, что идеи сами по себе хорошие.
Нет же, всё круто, всё правильно, просто использование этих технологий сегодня не даёт никакого профита.
Вот если бы гугл выкатил хотя бы один свой боевой проект, написанный на собственном Polymer, тогда можно было бы о чём-то говорить, а пока этого нет, разговор этот имеет смысл только в разрезе собственных поделок.
Вот вы говорите, что необходимо отказаться от популярных фреймворков/библиотек
Действительно? Где? По моему, я написал о том, что веб-компоненты можно использовать В СОЧЕТАНИИ с фреймворками и библиотеками. Ссылку на тесты привел. И это лишь один из интересных кейсов их применения.
Далее, простите, у меня нет сил это прокомментировать: я опять предположу что вы не читали, читали не внимательно или просто не поняли в чем суть. Допускаю, что в последнем случае, в этом есть моя вина, но я, честно, старался.
https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%3F — не стал изначально вставлять ссылку в статью, ибо она не о Polymer по большей части, а о стандартах на которых он основан. Но вот, любуйтесь.
хотя бы один свой боевой проект, написанный на собственном Polymer
эмм, ютуб? внутренний интерфейс хрома?
Никак не могу взять в толк, почему в каждой статье про WebComponents обязательно упоминается HTMLImports. Эта спецификация считается deprecated, её отказались имплементировать все браузеры, кроме Chrome. Я понимаю, что на HTMLImports написано подавляющее большинство современных вебкомпонентов, но это всего лишь наследие предыдущих версий Polymer.
А можно поинтересоваться, с чего вы взяли, что HTMLImports — deprecated? У них как был статус Working Draft, так и остался. Совершенно верно, что эту часть стандарта отказались внедрять производители браузеров всех кроме Chrome, но они пишут что ПОКА отказались. Поскольку эта спецификация была изначально включена, и реализована в Chrome и его производных — я о ней пишу. Хотя я написал, что сам ее не использую.
Надежда, как известно, умирает последней, по пока все идет по тому же пути, как умер Object.observe
- Поддерживается только в Chrome, остальные вендоры отказываются это имплементировать
- Ни один крупный фреймворк ими не пользуется (включая Polymer)
Официальной таблички "deprecated" на фичу пока не навесили, но идет работа по превращению html-модулей в расширение ES-модулей с отказом от синтаксиса <link rel="import">
Согласен с этим. Не согласен с позицией, что эту часть уже пора полностью игнорировать. Как ни крути, сама концепция — довольно интересна. Хотя-бы для того, чтобы быть в курсе тенденций, и этапов развития, о ней неплохо бы знать.
Ну так я и не рекомендую их использовать, тут я согласен с вами и разработчиками Polymer.
Простите, а как вы его пытались включить?
встроенные полифиллы
Гениально. Вы уверены, что понимаете о чем говорите?
Полифиллы можно включить для Chrome при помощи get-параметров, например: https://www.example.com/my-application/view1?wc-ce&wc-shadydom&wc-shimcssproperties
Задокументированно это тут, возможно на Youtube эту фичу оторвали, но в моем опыте эта штука помогала отлаживать баги, пользуясь удобными devtools Хрома и не запуская виртуалку.
Polymer уже тоже не рекомендуется использовать, почитайте их блог или последние доклады. Суть полимера — дать возможность «раннего доступа» к вебкомпонентам до реализации их в платформе, посмотреть как это в дикой природе выживает и лучшее взять в плаиформу. Сейчас на эту роль претендует LitElement
Что-то полетело — кастомные элементы и шедоу рут.
Что-то изменилось — html imports заменят на import в js, css mixins скорее всего сохранятся как идея но вроде будут представлять из себя что-то вроде кастомных предопределенных точек доопределения стилей (по аналогии с ::before и ::after можно будет создать в своем элементе my-element::super-button, но это пока ранний драфт, не ясно что будет в итоге).
Что-то нет — дата биндинги не полетели их в платформе не будет, вместо них предлагается использовать редакс и рендер-функцию для эффективной работы которой предлагается добавить в template поддержку чего-то вроде плейсхолдеров.
В общем статья уже во многом устарела. :-(
Дополню ваш комментарий парой ссылок :)
Что-то изменилось — html imports заменят на import в js, css mixins скорее всего сохранятся как идея но вроде будут представлять из себя что-то вроде кастомных предопределенных точек доопределения стилей (по аналогии с ::before и ::after можно будет создать в своем элементе my-element::super-button, но это пока ранний драфт, не ясно что будет в итоге).
Хорошие ссылки по теме — сам CSS Shadow Parts proposal и отличное описание того, как это предполагается использовать, от Monica Dinculescu.
Что-то нет — дата биндинги не полетели их в платформе не будет, вместо них предлагается использовать редакс и рендер-функцию для эффективной работы которой предлагается добавить в template поддержку чего-то вроде плейсхолдеров.
HTML Template Instantiation proposal.
HTML imports уже deprecated
Спрашивал уже у предыдущего комментатора, у вас тоже спрошу: откуда такие новости?
скорее всего поддержат импорты html в js через стандартный import.В смысле, "скорее всего"? Именно так это и работает в Polymer 3.0, и именно этот подход рекомендую я.
Polymer уже тоже не рекомендуется использовать
If your project has a short development cycle and you're uncomfortable with including pre-release dependencies in your production deployments, you might choose to use Polymer 3.0 instead. This is a safe choice, as we'll continue to support the Polymer 3.x APIs with maintenance releases for the foreseeable future.
Цитата из последнего сообщения в блоге разработчиков. Знаете, я тут пытаюсь заниматься популяризацией новых фишек веб-платформы и вопросы готовности технологий к использованию — самые труднопробиваемые. А вы мне предлагаете писать о вещах, которые in development? В свое время — обязательно напишу, сейчас — явно рано. Статья точно пока не устарела.
Часть про биндинги не буду комментировать, вы видимо, торопились сильно когда писали.
Пробую сейчас использовать custom elements.
Существенный недостаток — на момент вызова connectedCallback нет доступа к child элементам. Как делать вложенные элементы, такие как свой select с options?
Или первая отрисовка будет основана только на основе атрибутов элемента (дублируем selected option атрибутом) или откладывать отрисовку на setTimeout, но это визуально же мерцание.
В итоге сделал перечисление всех options json'ом в аттрибуте. Для серверной генерации удобно, но руками конечно не напишешь.
Хм, а вы ничего не путаете? Проверяю, все доступно:
connectedCallback() {
console.log(this.children);
}По ссылке на StackOverflow описана какая-то странная вымороченная ситуация и еще код приведен с поиском дочернего элемента внутри Shadow DOM, хотя он лежит внутри обычного DOM как обычный потомок элемента…
Делал и селекты и табы и прочее подобным образом, проблем не было. Лучшим вариантом для подобных случаев считаю что-то типа этого:
<my-select>
<my-option icon="some-icon" value="opt-1">Option Text</my-option>
</my-select>Где оба элемента — обычные custom elements (мутации вложенных элементов родительским в момент добавления в DOM — не нужны)
Думаю это может помочь:
При поиске веб-компонентов внутри теневого DOM компонента, может возникнуть ситуация, когда элемент существует как неизвестный HTML-элемент пока конструктор компонента еще не был вызван. В этом случае, все собственные методы компонента будут недоступны, а назначенные свойства будут хранить свои значения только до того момента, пока что-либо во время инициализации такого компонента их не изменит или не определит для них функцию-аксессор. Эту ситуацию можно победить примерно таким образом:
constructor() {
super();
// Сохраняем ранее назначенное значение:
this._myProp = this.myProp;
Object.defineProperty(this, 'myProp', {
set: (value) => {
// Тут описываем сеттер...
},
};
// Присваиваем значение, но уже через корректный аксессор:
this.myProp = this._myProp;
}Подобным образом можно поступать и с методами, например, определяя их снаружи компонента, а потом восстанавливая их в конструкторе внутреннего компонента. Я думаю это может быть допустимо в случае сильно-связанных компонентов типа внешнего my-select и внутренних my-option. Но лучше, конечно, этого избегать.
Если вызывать window.customElements.define до загрузки страницы (непосредствнно в head) то this.chiildren.length == 0, если после, то 1
gist.github.com/kmmbvnr/25ac3487b16ce07df82b1eaab0e1bbf2
Скорее всего фреймворки никуда не уйдут, просто view часть у них пкрекдет на веб компоненты. Роутинги, формы, анимации хранение состояния далеко не полный перечень всего что есть во фреймворках и нет в веб компонентах.
Скорее всего фреймворки никуда не уйдут, просто view часть у них пкрекдет на веб компоненты.
Полностью согласен. Ну, кроме анимаций =) Никто и не позиционирует веб-компоненты как замену фреймворкам, скорее их стоит рассматривать как основу для фреймворков нового поколения.
Вот бы они еще запилили Object.observe еще бы пару фреймворков отвалилась.
Есть же Proxy
Еще раз о веб-компонентах…