настройка пользовательских элементов: конструктор против connectedCallback - PullRequest
Новая
       32

настройка пользовательских элементов: конструктор против connectedCallback

2 голосов
/ 29 января 2020

Я новичок в веб-компонентах, и я заметил, что некоторые примеры устанавливают dom в конструкторе пользовательского элемента, в то время как другие делают это в connectedCallback. Поскольку оба варианта работают нормально (хотя я пробовал только Chrome), я предполагаю, что основным отличием является случай, когда пользователь создает элемент в js, а не присоединяет его к странице?

I угадайте, что главный вопрос здесь заключается в том, упускаю ли я какую-то другую причину, чтобы отдавать предпочтение одному методу над другим.

1 Ответ

4 голосов
/ 29 января 2020

Лучшие практики и правила для конструкторов пользовательских элементов

Что безопасно делать в конструкторе

В constructor безопасно

  • создать shadow root;
  • создание и добавление элементов *;
  • присоединение прослушивателей событий к этим элементам (ограничено ваш собственный ShadowDOM);
  • создать атрибуты *.

Что вы не можете сделать в конструкторе

В constructor вы не разрешено (среди прочего)

  • для чтения любых атрибутов, которые вы ранее не создавали ...
  • для доступа к дочерним элементам ...

... потому что они могут отсутствовать в случае отсутствия обновления и определенно не будут присутствовать при динамическом создании пользовательского элемента с использованием document.createElement('my-custom-element') или new MyCustomElement.

Что неразумно делать в constructor

В constructor вы, вероятно, не хотите

  • прикреплять прослушиватели событий к элементов вне теневого компонента DOM (например, document, window), потому что именно такие слушатели вы должны очистить в disconnectedCallback вашего компонента (который будет вызываться, когда, например, ваш компонент перемещается в DOM).

Подключение этих слушателей в конструкторе и их правильная очистка в disconnectedCallback приводит к отсутствию слушателей, как только ваш компонент будет удален (а затем повторно добавлен) или перемещен в DOM.

* Подводные камни и вещи, о которых следует знать

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

  • Если вы добавьте атрибуты в constructor и включите их в observedAttributes вашего компонента, помните, что это немедленно вызовет attributeChangedCallback для этих атрибутов, даже если ваш элемент еще не подключен (он же в DOM ).
  • Если вы создаете и добавляете другие пользовательские элементы в теневой DOM вашего компонента, помните, что это приведет к запуску этих компонентов: connectedCallback.

Частично эти рекомендации и правила следуйте https://html.spec.whatwg.org/multipage/custom-elements.html#custom -элемент-соответствию , в других частях они отличаются от рекомендаций, сделанных в спецификации c.

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

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

...