Что такое делегирование событий

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

Событие происходит на конкретном элементе, затем поднимается вверх по DOM-дереву. Родительский обработчик получает событие и проверяет, подходит ли исходный элемент под нужное действие.

На интервью можно ответить так:

Делегирование событий это один обработчик на родителе, который обрабатывает события от потомков за счет всплытия. Внутри обработчика я проверяю event.target или ближайший подходящий элемент через closest(). Это удобно для списков и динамического DOM, но работает не для всех событий.

На интервью лучше не ограничиваться проверкой event.target.tagName. Пользователь может нажать на иконку или текстовый span внутри кнопки. Тогда удаление может не сработать, аналитика получит неверное действие или клик обработается не на той строке.

Более надежный вариант ищет ближайший элемент с нужным атрибутом и проверяет, что он находится внутри контейнера.

const list = document.querySelector("[data-list]");

list?.addEventListener("click", (event) => {
  const target = event.target;

  if (!(target instanceof Element)) {
    return;
  }

  const button = target.closest("[data-action='remove']");

  if (!button || !list.contains(button)) {
    return;
  }

  const item = button.closest("[data-item]");

  if (!item || !list.contains(item)) {
    return;
  }

  item.remove();
});

Здесь data-action отделяет поведение от конкретного тега, а contains() защищает границу контейнера. Такой код спокойно переживает вложенные иконки, новые элементы списка и небольшие изменения верстки.

Не применяйте делегирование автоматически. Оно хорошо работает, когда элементы однотипные и действие можно определить по селектору, id или data-* атрибуту. Если каждый дочерний компонент живет своей сложной жизнью, локальный обработчик может быть проще для чтения и тестирования.

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

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

Делегирование зависит от того, дойдет ли событие до родителя. Для обычного click это чаще всего работает ожидаемо. Но focus и blur не всплывают как обычные клики, поэтому обработчик на родителе их не поймает в стандартной схеме.

Если нужно похожее поведение для фокуса, используйте focusin, focusout или обработчик в capture phase. В ответе лучше сказать это явно. Фраза "делегирование работает для любых событий" звучит уверенно, но технически неверна.

В React не всегда нужно вручную переносить DOM-паттерн один в один. React использует собственную систему событий и сам управляет обработчиками JSX-событий. Поэтому обычный список с onClick на кнопке внутри элемента не означает, что вы создали тяжелую ручную систему из сотен нативных обработчиков.

Но родительский обработчик все равно может быть полезен, если у списка много однотипных действий и код становится проще:

function ActionsList({ items, onRemove }) {
  function handleClick(event) {
    const target = event.target;

    if (!(target instanceof Element)) {
      return;
    }

    const button = target.closest("[data-remove-id]");

    if (!button || !event.currentTarget.contains(button)) {
      return;
    }

    onRemove(button.dataset.removeId);
  }

  return (
    <ul onClick={handleClick}>
      {items.map((item) => (
        <li key={item.id}>
          <button type="button" data-remove-id={item.id}>
            Remove
          </button>
        </li>
      ))}
    </ul>
  );
}

В примере действие остается на настоящей кнопке. Это важно для фокуса, клавиатуры и доступного имени. Делегирование не должно превращать интерфейс в набор кликабельных div без семантики.

Если вы добавляете нативный addEventListener вручную, например на document или window, это уже не обычный JSX-обработчик. В таком случае нужен cleanup. Иначе после размонтирования компонента можно получить лишние вызовы, утечки и странные баги.

На интервью важно не просто дать определение, а показать безопасное правило. Двигайтесь в таком порядке: один обработчик на родителе, работа через всплытие, проверка цели события, польза для динамических элементов, ограничения для событий без всплытия.

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