Re: [w3c/webcomponents] [idea] distributedCallback for Custom Elements (#527)

@rniwa 

[Speaking of events](https://github.com/w3c/webcomponents/issues/528#issuecomment-233215621), it seems that a framework can asynchronously map the "flat tree" if the end user of the framework places custom elements from that framework at the root of the app and at a leaf positions, and finally triggering events, at which point `Event.prototype.composedPath()` will reveal one full branch of the flat tree?

I wanted to point out that `distributedCallback` would allow the same thing, for a framework to map the the flat tree (composed tree), but synchronously instead of asynchronously and with stricter requirements because it would require the framework to have a custom element placed into each shadow layer. So, the framework would be able to map the flat tree limited only to portions of the shadow layer hierarchy (if we were to visualize a tree of the shadow layers and child shadow layers) where the framework has custom elements from one layer to the next. As soon as one layer is missing the custom elements, then cooperating third party frameworks would be required to bridge that gap.

**I think it's a good idea.**

The reason I need this (or something similar) is to guarantee synchronous discovery (or lack of discovery, which is what I *really* want) of the flat tree between two shadow layers when my library's custom elements are used on both sides of the shadow boundary.

With strictly events, as it currently stands, this can only be achieved with event polling (we must poll because there's no way for an element to know it has been distributed because there's nothing like `distributedCallback`), which is very ugly.

Suppose we do write an event polling mechanism. Then, `distributedCallback` would allow us to change from a polling method to a one-shot method in `distributedCallback`, without having to re-write all the event-based code.

But, if something like `distributedCallback` existed to begin with, then the event code would not be needed, and only some synchronous code in `distributedCallback` along with synchronous code in a parent's `slotchange` handler (keeping in mind the above idea that `slotchange` should fire before `distributedCallback`s of the elements distributed into the associated `slot`).

Quick question, which code can listen to `slotchange` events? Is there certain places where code that runs cannot listen to `slotchange`? If so, how does that work?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/527#issuecomment-233217944