Кроме изоляции стилей, Shadow DOM влияет и на то, каким образом они добавляются на страницу. Тред о том, что это значит на практике и каких улучшений стоит ждать в обозримом будущем.
Размещать стили внутри Shadow DOM обычно рекомендуется с помощью элемента <style>. Для тех, кто придерживается строгих правил CSP, это означает необходимость unsafe-inline.
Современные браузеры кэшируют содержимое <style>, так что на производительность этот способ не влияет. Можно использовать и <link rel=“stylesheet”>, но так обычно не делают из-за FOUC.
developer.mozilla.org/en-US/docs/Web…
Еще есть Constructable Stylesheets — эксперимент, реализованный только в Chrome и по их замерам более производительный. Это API используется в lit-element с фолбеком на <style> для Firefox и Safari.
developers.google.com/web/updates/20…
По инициативе разработчиков WebKit идет обсуждение, каким образом устранить выявленные недостатки в этом API. В связи с наличием двух разных позиций дискуссия затянулась.
github.com/WICG/construct…
Важен этот черновик тем, что является одной из ступенек на пути к Cascading Stylesheet Module Scripts. В перспективе это возможность нативно импортировать стили из CSS-файлов в JavaScript.
github.com/WICG/webcompon…
Рабочее название этого API — “CSS modules”. Хотя против него были возражения в связи с тем, что существует популярная библиотека с таким названием и могла бы возникнуть путаница.
github.com/WICG/webcompon…
Но черновики — вопрос будущего, а пока мы говорим об элементах <style>, добавление которых требует JS. Стоит ли полагаться на такой подход? Решайте сами, исходя из конкретных задач.
Пример реализации для React — библиотека Cease, всего 30 строк и 500 байт без зависимостей. Советую заглянуть в ее документацию, там хорошо описаны подводные камни Shadow DOM.
github.com/steobrien/cease
Также рекомендую пример конфигурации webpack и style-loader для работы с Shadow DOM в проектах на React и Vue, приведенный во второй части статьи Дениса Мишунова о Frankenstein Migration.
smashingmagazine.com/2019/09/franke…