4

I'm studying LWC Events and came across bubbles and composed. I'm not able to understand the need for both.. Let's consider two components 'Component A' && 'Component B', A is the parent here.

From my understanding, for whatever event happens in component B:

  1. bubbles is used to allow event bubble up through the the DOM, so ideally if I set bubbles as true, it'd not allow event propagation outside of Component B.

  2. If I set composed as true, it allows the parent component to listen to the event as well.

However, the 2nd point can be achieved even by using the customevent() on event target by dispatching event which can then be listened by the parent component.

And, the first point, where events are bubbled only inside the component where the event occurred. Now, whatever we want to do once event occurs, why do we even need to bubble it? we can achieve any functionality within the same component without even bubbling it.. Can't we?

Can someone please help me understand why we really need bubbles and composed, not able to understand much from documentation.

Can someone please explain this concept using an example?

2 Answers 2

14

The documentation contains clear examples of each. It helps to have a more complicated example to work with. If you only think in terms of A and B, the other models have no meaning (and thus, would seem pointless). You need at least 3 levels of nested components to see any meaning at all.

parent-component

<template>
  <div onnotify={handleOuterNotify}>
    <c-my-component onnotify={handleInnerNotify}>
    </c-my-component>
  </div>
</template>

my-component

<template>
  <c-another-component />
</template>

bubbles = false, composed = false

A notify event from c-my-component will only fire handleInnerNotify.

bubbles = true, composed = false

A notify event from c-my-component will fire handleOuterNotify and handleInnerNotify; this allows you to place event handlers on ancestors of the source.

bubbles = true, composed = true

When c-another-component fires a notify event, both handleInnerNotify and handleOuterNotify will fire, even though the default configuration would have been stopped at the c-my-component boundary.

As you can see, they are increasing levels of effect. Almost all events should use the default configuration. This is perfectly sane and usually desirable. Bubbling is less common, but may be useful if you want to have HTML-like DOM behavior (such as handling an onclick on a parent element). The final configuration is definitely a very rare use case (I can't think of a good example), but it's there if you absolutely needed something that behaved something like an "application event" in Aura terminology but coudln't use pubsub (the recommended choice for directed events).

You'll notice I left out bubbles = false, composed = true. This configuration isn't supported and therefore has undefined behavior.


Edit: Added an example script.

6
  • One use case would be when listening to events on a javascript level through lightning out in Visual force. for example, Google Maps customizations done in VF, but using lightningout for form interaction. using bubbles = true, composed = true allows the VF outside of the Lightning out to hear the event and be able to use them with other JS APIs that don't work have as much functionality in LWC. Edge case, but i am sure other APIs may see similar usages.
    – Ronnie
    Apr 3, 2020 at 2:43
  • @sfdcfox b=t, c=f & b=t, c=t appear the same. Can you please provide a better example for compose=true? As per the LWC docs for b=t, c=t "The event bubbles up through the DOM, crosses the shadow boundary, and continues bubbling up through the DOM to the document root.". Is there any significance for shadow boundary in the example you've provided?
    – user61140
    Jan 27, 2021 at 20:16
  • @user61140 I added an example for you (and future visitors). It shows how BT,CT differs from BT,CF; in c-grandchild, BT,CF doesn't trigger on c-child, but does trigger on c-parent's div handler, while BT,CT does trigger on c-child. Does this help?
    – sfdcfox
    Jan 27, 2021 at 21:07
  • 1
    @sfdcfox Thanks for the example. It does help. But, why it doesn't trigger on c-child? I tried to play around with the given example and I'm not sure why it's happening.
    – user61140
    Jan 28, 2021 at 5:34
  • 1
    @user61140 That's just how they're specified. When composed is false, no other custom elements will see the event aside from the direct parent, if any. All standard elements will get anything that bubbles. This is why c-child doesn't see BTCF events from c-grandchild, because the composed bubbling has stopped. This is usually desirable, as BTCT events become part of every parent component's API, which is generally bad.
    – sfdcfox
    Jan 28, 2021 at 12:34
1

Just going to add a link to this blog article; it does a brilliant job of explaining the bubbles and composed properties of Event dispatching and the relationship with the ShadowDOM

https://developer.salesforce.com/blogs/2021/08/how-events-bubble-in-lightning-web-components - "How Events Bubble in Lightning Web Components"

1
  • 1
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – identigral
    May 16, 2023 at 16:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .