Почему пользовательские события предпочтительнее обратных вызовов атрибутов в веб-компонентах?

В веб-компонентах, как и в React, мы отправляем данные вниз, а события - вверх.

В React обычно отправляют событие в дочерний компонент в качестве атрибута. Например:

<CustomComponent handleClick={this.handleClick}></CustomComponent>

Я узнал, что это также можно сделать с помощью веб-компонентов LitElement:

<custom-component .handleClick=${this.handleClick}></custom-component>

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

this.dispatchEvent(
    new CustomEvent('some-custom-event', {
        bubbles: true,
        composed: true,
        detail: {
            data: someData,
        },
    })
);

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


javascript web-component polymer lit-element
person rikil    schedule 23.10.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

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

person sfeast    schedule 24.10.2019
comment
Спасибо за ответ! Я тоже слышал о развязке. Однако мне любопытно, всегда ли важно разделять веб-компоненты. например, что, если компонент никогда не будет изолирован? Требуя атрибуты, вы можете гарантировать, что будет выдана ошибка . Таким образом, при использовании компонента вы можете быть уверены, что если атрибуты не переданы, вы получите сообщение об ошибке и знаете, как отладить проблему. Это проблемное мышление? Не лучше ли выдать ошибку, чтобы я как разработчик мог быть уверен, что правильно реализовал веб-компонент? - person rikil; 24.10.2019
comment
Обновил мой комментарий, извините за раннюю отправку. - person rikil; 24.10.2019
comment
«разделение» зависит от вас как архитектора / разработчика / пользователя. Склеиваю свою мебель из ИКЕА. Точно так же я использую как методы, так и события с WebComponents, с предпочтением для событий. Примечание: вы можете смешивать оба, передавая ссылки на методы в Event.detail stackoverflow.com/questions/55001211/ - person Danny '365CSI' Engelman; 24.10.2019
comment
Да, я стараюсь сбалансировать время / усилия и элегантный код, при необходимости рефакторинг позже. Я бы сказал, что это зависит от конкретного сценария - может быть, вам нужно переосмыслить архитектуру или рассмотреть другой шаблон (например, составные компоненты) ИЛИ, возможно, имеет смысл делать то, что вы говорите в определенных ситуациях, по крайней мере, для эффективности . В целом, хотя я бы не требовал глубокого понимания внутренней работы компонента, передача обратных вызовов часто приводит к необходимости большей координации между дочерним и родительским, особенно если вы меняете рассматриваемый компонент, что делает отношения более хрупкими. - person sfeast; 25.10.2019