2

In web-components, similar to React, we send data down, and events up.

With React, it's common to send an event into a child component as an attribute. For example:

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

I've learned that it's also possible to do this with LitElement web-components:

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

However, many sources I've read say to use a custom event from within the component without ever mentioning attribute callbacks:

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

My question is, why is it preferred to dispatch a custom event rather than send a callback to the web component as an attribute? Is it convention or is there a strong reason that I just can't find?

rikil
  • 23
  • 5

1 Answers1

4

If I understand your question correctly I believe the answer is that using event handlers vs passing a callback to a child component is to achieve a more loosely coupled architecture.

For example, in the situation where a callback is passed down, if the parent of the component in question did not implement (or pass) a callback then an error would be thrown when the child component tried to use it, whereas in the event handling situation there's likely less chance of errors if the parent just doesn't handle the event.

Probably more important than errors though it's often the case that a component is more flexible & easier to understand for other developers using it when using event handlers vs callbacks since it may require less understanding of the internal workings of the component.

There are exceptions to this of course but generally it's a best practice for more usable & well-designed components.

sfeast
  • 956
  • 5
  • 7
  • thank you for the response! The decoupling is what I've been hearing as well. However, I'm curious if it is always important to decouple web components. for example, what if the component will never stand alone? By requiring attributes, you can ensure that an error *is* thrown. This way when you use the component you can ensure that if the attributes aren't passed, you get an error and know how to debug the issue. Is this problematic thinking? Would it not be better to throw the error so that as a developer I can be sure that I've implemented the web component properly? – rikil Oct 24 '19 at 15:27
  • Updated my comment, sorry for the early submit. – rikil Oct 24 '19 at 15:32
  • 'decoupling' is all up to you as architect/developer/user. I glue my IKEA furniture. Likewise I use both Methods and Events with WebComponents, with a preference for Events.. Note: You can mix both, passing references to methods in Event.detail https://stackoverflow.com/questions/55001211/how-to-communicate-between-web-components-native-ui – Danny '365CSI' Engelman Oct 24 '19 at 15:40
  • Yeah I try to balance time/effort vs elegant code, refactor later if needed. I'd say it depends on the specific scenario - could be that you need to re-think the architecture or consider another pattern (like compound components) OR maybe it does make sense to do what you say in certain situations, at least for efficiency. Generally though I'd avoid requiring much insight into the internal workings of a component, passing in callbacks often leads to more coordination being required between child & parent, especially if you change the component in question, makes the relationship more brittle. – sfeast Oct 24 '19 at 23:21