Что такое Shadow DOM

Shadow DOM нужен, когда компоненту нужна своя внутренняя DOM-структура и свои стили. Они не должны случайно конфликтовать со страницей. Элемент, к которому прикрепляют Shadow DOM, называется shadow host. Корень внутреннего дерева называется shadow root. Все внутреннее поддерево называют shadow tree.

На интервью удобно начать так:

Shadow DOM это часть Web Components. Он позволяет прикрепить к элементу отдельное DOM-поддерево и изолировать внутреннюю разметку и стили компонента от основного документа. Это удобно для переиспользуемых компонентов, дизайн-систем и виджетов, которые могут оказаться в чужом CSS-окружении.

Не обещайте больше, чем технология дает. Shadow DOM не делает код секретным, не заменяет iframe и не является Virtual DOM из React.

Базовый пример показывает host, shadow root, внутреннюю разметку и локальные стили:

const host = document.querySelector("#profile-card");
const root = host.attachShadow({ mode: "open" });

root.innerHTML = `
  <style>
    :host {
      display: block;
      font-family: system-ui;
    }

    button {
      color: white;
      background: rebeccapurple;
      border: 0;
      border-radius: 6px;
      padding: 8px 12px;
    }
  </style>

  <button type="button">Подписаться</button>
`;

root.querySelector("button").addEventListener("click", () => {
  host.dispatchEvent(
    new CustomEvent("subscribe", {
      bubbles: true,
      composed: true,
      detail: { source: "profile-card" },
    })
  );
});

Селектор button внутри style действует только на кнопку внутри shadow tree. Глобальное правило страницы для button не должно переписать эту кнопку напрямую. Событие subscribe специально сделано публичным. Так внешний код не зависит от внутренней кнопки.

В этом примере innerHTML содержит только статическую разметку автора компонента. Если подставить туда имя пользователя, ответ API или HTML из CMS без проверки, Shadow DOM не спасет от XSS. Для текста безопаснее создавать узел и писать в textContent:

const name = document.createElement("span");
name.textContent = user.name;
root.append(name);

Если компоненту правда нужен HTML из внешнего источника, используйте проверенный sanitizer и узкий список разрешенных тегов. Не делайте безопасность зависимой от mode: "closed".

Shadow DOM создает границу для DOM-запросов и CSS-селекторов. Например, document.querySelector("button") не найдет кнопку внутри shadow tree. Внешний CSS-селектор .card button не применится к внутренней кнопке.

Но это не абсолютная изоляция. Наследуемые CSS-свойства, например цвет текста или шрифт, могут приходить от host. CSS custom properties тоже могут проходить через границу. Их часто используют как публичный API для темы.

profile-card {
  --card-accent: rebeccapurple;
}

/* внутри Shadow DOM */
button {
  background: var(--card-accent, black);
}

Практический вывод простой. Если компонент должен настраиваться снаружи, заранее спроектируйте точки настройки. Не рассчитывайте, что внешний разработчик будет лезть во внутренние классы.

Shadow DOM особенно полезен, если компонент будут вставлять в среду, которую вы не контролируете. Это может быть маркетинговая страница, CMS, страница партнера или legacy-приложение. Там любой глобальный button, * или .title может неожиданно сломать UI.

Если у вас обычное приложение с контролируемым стеком и командными соглашениями, Shadow DOM может быть лишним усложнением. Он меняет подход к стилям, тестам, событиям и интеграции с библиотеками.

Для стилей полезно назвать :host, CSS custom properties и иногда ::part. :host стилизует сам host изнутри Shadow DOM. CSS-переменные помогают сделать тему контролируемой. ::part можно использовать, если компонент явно открывает часть внутренней разметки для стилизации снаружи.

Для событий главное правило такое: не заставляйте внешний код знать внутреннюю DOM-структуру. Если пользователь кликнул внутреннюю кнопку, компонент может отправить понятное событие, например subscribe, change или close. Тогда внутреннюю кнопку можно переименовать или заменить без поломки интеграции.

Shadow DOM не делает кастомный UI доступным автоматически. Если внутри стоит нативная button, браузер уже дает фокус, клавиатуру и роль. Если кнопку заменили на div с click, пользователи клавиатуры могут потерять действие.

Есть еще один практический нюанс. Внешний label for не должен быть единственным способом подписать внутренний input. ID внутри shadow tree живут в своей области. Для компонента нужно заранее продумать публичное имя, slot для подписи или aria-атрибуты.

На интервью достаточно сказать так: Shadow DOM помогает со стилями, но не отменяет проверку фокуса, Tab-порядка, имени контрола и поведения клавиатуры.

При создании Shadow DOM нужно выбрать режим:

const openRoot = host.attachShadow({ mode: "open" });
console.log(host.shadowRoot === openRoot); // true

const closedRoot = anotherHost.attachShadow({ mode: "closed" });
console.log(anotherHost.shadowRoot); // null

open означает, что внешний JavaScript может получить shadowRoot через host. closed скрывает эту ссылку от стандартного доступа через host.shadowRoot.

На интервью важно не сказать, что closed надежно защищает компонент. Это не security boundary. Это способ ограничить публичный доступ к внутренностям. Но он усложняет отладку, тестирование и поддержку. Поэтому для большинства учебных и продуктовых компонентов open объяснить проще и честнее.

В ответе держите баланс. Сначала дайте определение, потом объясните пользу, затем назовите ограничения.

Хорошая структура ответа:

1. Shadow DOM это изолированное поддерево DOM у host-элемента.
2. Оно помогает компоненту не конфликтовать со стилями и DOM страницы.
3. Внутри есть shadow root, shadow tree. Для внешнего содержимого можно использовать slots.
4. Граница не абсолютная. Есть CSS-переменные, наследование, события и режимы open или closed.
5. В реальной работе это полезно для Web Components, виджетов и дизайн-систем. Но Shadow DOM не нужен автоматически для каждого компонента.
6. Для клиентской безопасности и доступности нужны отдельные решения. Не вставляйте непроверенный HTML, не храните секреты в DOM, проверяйте фокус и клавиатуру.

Такой ответ показывает, что вы знаете термин и понимаете последствия для UI, безопасности, доступности, тестов и интеграции.