Comments 22
Вспомнил случай на работе (ровно год назад): хочу отдебажить вебвью в старом андроиде, подключаю телефон к ноуту, иду в remote devices в хроме (80), выбираю свое вебвью и… вижу белый экран вместо девтулзов. Быстрое расследование показало, страничка девтулзов сама падает с ошибкой document.registerElement is not a function
Пытливому читателю предлагается угадать, на какой технологии сделаны девтулзы андроидного вебвью и какую технологию выпилили под 0 в свежем хроме.
https://www.chromestatus.com/feature/4642138092470272
Because React implements its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of a workaround. Developers will need to reference their Custom Elements using a ref and manually attach event listeners with addEventListener. This makes working with Custom Elements cumbersome.
Ведь это действительно, иногда превращается в ад — попытка использовать вэб-компоненты в реакте. Он их спокойно разместит в dom-дереве, привяжется к пропертям, но вот привязать обработчик кастомного события — действительно, только через рефы. Да и вообще, спека кастомных событий рождалась не для удовлетворения потребностей именно вэб-компонентов, но для удовлетворения потребностей вэб-разработчиков.
Хорошо или плохо? Реакт решает одну хорошую и важную задачу — делает строго однонаправленный поток данных. Делает он это ценой того, что он старается держать весь поток внутри своей абстракции. И любые попытки выскочить из нее — потенциальные точки нарушения направленности потока данных. Именно поэтому разработчики этой библиотеки рекомендуют использовать рефы только в крайних случаях, когда другие способы не помогли.
Реакт не дружит с вэб-стандартами, он их оборачивает своими абстракциями, считая что это единственный верный способ реализации вэб-приложений.
В тоже время, существует много кейсов, где модель реакта не так эффективна, как реализация на чистом DOM/Custom Elements
Все правильно пишите, за одним маленьким исключением: веб-компоненты != веб-стандарты. В одном из прошлых постов я раскрывал эту тему более подробно: https://habr.com/en/post/486500/
В тоже время, существует много кейсов, где модель реакта не так эффективна, как реализация на чистом DOM/Custom Elements
Расскажите про эти кейсы, будет полезно знать.
А вот с приложением, реализованном на фреймворках/либах более дружественно относящихся к DOM и веб-стандартам, такая задача легко решается, либо проблема вообще не возникает.
И да, у вэб-компонентов нет единого стандарта, что в прочем хорошо. Потому как они базируются на семействе вэб-стандартов, которые могут развиваться уже по своей собственной траектории.
Разработчик же имеет возможность выбирать ту технологию/реализацию, которая ему больше подойдет для конкретной реализации. Нужна изоляция стилей: БЭМ, linaria, Shadow DOM, выбирай что тебе удобно. Нужен встраиваемый виджет: IFrame, вэб-виджет, вэб-компонент на шедоу или лайт DOM, ну или еще что там придумаешь.
Анализируй поставленную задачу и выбирай инструмент.
Мне лично для A/B тестов всегда хватало какого-то такого кода: isFeatureEnabled ? <ComponentA /> : <ComponentB />. Возможно, есть более сложные сценарии, но я почему-то сомневаюсь, что такая большая компания как Facebook сделала бы фреймворк, не способный к A/B тестированию
Но вот на практике всегда все сложнее. Особенно когда нужно, и часто нужно, проверить хоть какой-то потенциал гипотезы, прежде чем выделять ресурсы на реализацию ее фич.
но я почему-то сомневаюсь, что такая большая компания как Facebook сделала бы фреймворк, не способный к A/B тестированию
С большим интересом посмотрю на фреймворк для эксперементирования от Facebook. Особенно на ту его часть, где будет решаться проблема внедрения в реакт-дерево.
Следование принципам DOM актуально для кого? Для SEO'шника? Зачем вообще нужен React на странице, которая отдаётся в ранжирование?
Автор этой странички считает это хаком и настаивает на том, что поддержка должна быть встроена во фреймворк. Получается, что результаты этого теста основаны на субъективном мнении, а не технической возможности/невозможности решить задачу.
Все известные мне фреймворки так или иначе дают разработчику взможность работать напрямую с ДОМ-нодами. Следуя вашей логике — все они 100% дают техническую возможность решить задачу, если собственно ДОМ ее поддерживает. Такой подход лишает эту оценку совместимости всякого смысла.
Таким образом, необходимость создания оберток, из-за которой React влепили его 71% рейтинга, не помешала дать Angular 100%. Вот такой вот непредвзятый рейтинг.
Да нет же. Просто на событие с двоеточием автор не написал теста. Почему не написал — это уже другой вопрос: предвзятость или упущение или еще что. Но 100% у Ангуляра не потому, что "необходимость создания оберток" проигнорировали, а потому что все написанные тесты выполняются — вот и все.
Ещё до публикации статьи я отправил в их репозиторий вопрос о пропущенном тест-кейсе на события с двоеточием: https://github.com/webcomponents/custom-elements-everywhere/issues/986 ответа пока нет, но если он появится, обновлю пост.
Основная мысль остается той же: как вы справедливо замечаете, все фреймворки дают прямой доступ в ДОМ и непонятно, какой смысл измерять совместимость.
Просто в реакте хоть это и можно делать через прямой доступ, однако же веб компоненты использовать очень больно. Да реакт shadow root начал поддерживать то с 17 версии, до этого он вешал event listeners на document, из-за чего реакт приложение нельзя было заворачивать в shadow dom. (Ага, осталось дождаться поддержки от вебпака, я так и не смог заставить вебпак подключать стили внутрь shadow dom)
Отсутствие синтаксического сахара в JSX для поддержки свойств/событий это наименьшая из проблем. Как показывает опыт Stencil и других проектов, обертки генерируются простейшим образом, плюс дают дополнительные бонусы, вроде тайпингов и нормально работающего tree-shaking.
Гораздо больше проблем в самом косячном стандарте веб-компонентов.
Дискутировать с деврелами Chrome по-русски на Хабре — это конечно очень дерзко. Ох уж эта удивительная особенность русскоязычного сообщества жаловаться на браузеры в Твиттере, критиковать стандарты на Хабре — и всё по-русски. Чтобы наверняка никто не ответил, особенно автор тестов.
Если возможность добавления событий есть, то почему же тогда это не делается в тестах custom-elements-everywhere? Автор этой странички считает это хаком и настаивает на том, что поддержка должна быть встроена во фреймворк. Получается, что результаты этого теста основаны на субъективном мнении, а не технической возможности/невозможности решить задачу.
Гланды вырываются? Вырываются. Плевать, что через жопу. Ставим галку. А для жопы вазелин пропишем.
вот этот маленький модуль, который научит JSX работать и со свойствами, и с событиями как надо
Встаньте на табурет. Дотянулись? Отлично, ставим ещё одну галку. Пойдёте в баскетболисты.
А если серьёзно, то это какое-то бодание осла с козлом. Обе технологии довольно кривые. Обе 10 лет уже костыляют, а там до сих пор детские болезни.
Заинтересовали. А как обозначенные проблемы решаются в $mol фреймворке?
Как обычно, в $mol проблемы не решаются, они в нём просто не создаются. Например, в компонентах есть отдельные свойства, через которые задаются атрибуты (attr), поля (field), события (event) и стили (style). Соответственно, передавать туда можно всё, что сможет переварить браузер. Но работа с ними напрямую идёт относительно редко, основной метод коммуникации компонент — связывания свойств.
С явными секциями для свойств/атрибутов все понятно, по сути это вариант #4 из списка в первом комменте
А вот с этим моментом непонятно:
$my_widget $mol_view
title \Что будет в HTML, свойство или атрибут?
Ничего не будет, это свойство компонента. Чтобы оно попало в html его надо прибиндить в соответствующий словарь.
статья ради статьи, такое себе
Нарушает ли React DOM-стандарты?