Re: [w3c/webcomponents] A way to detect if a custom element was constructed during customElements.define call? (#790)

I think the questions are better here because they help standards implementers have better visibility into what users of the API are doing or want to do, and how. Do you think that's the case? Or do the implementers view the questions on SO?

> ```js
>     if (this.children.length) {
> ```

About that, that isn't enough. At that point if a child isn't upgraded yet, we can not see upgraded props/methods on the children. That's why I opened https://github.com/w3c/webcomponents/issues/789. So in that case, I create a `MutationObserver`, and it _does_ fire for the children _after_ they are upgraded.

So as a result of previous discussion in https://github.com/w3c/webcomponents/issues/789 and https://github.com/w3c/webcomponents/issues/787, the last implementation that I had before opening this one was the one in https://github.com/w3c/webcomponents/issues/787#issuecomment-459999420.

But now that I've come across the case of defining elements _after_ parsing (all of them at once, because doing them individually in different turns of the JS event loop will be another case), I've discovered that I need to handle this too, but because `connected` and `disconnected` callbacks are all synchronous in this case, I need unfortunately figure a way to call my `childConnectedCallback`s synchronously **_after_** the `connectedCallback` stack of my class hierarchy so that I can have them fire in the same order as during parsing.

Here's the order I see in the console when I define elements before parsing:

```
CONNECTED Scene
CONNECTED AutoLayoutNode
CHILD CONNECTED parent: Scene child: AutoLayoutNode
CONNECTED Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CONNECTED Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CONNECTED Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CONNECTED Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CONNECTED Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
```

and if I defer `childConnectedCallback`s to a microtask in `connectedCallback` like you see in https://github.com/w3c/webcomponents/issues/787#issuecomment-459999420, then the order is

```
CONNECTED Scene
CONNECTED AutoLayoutNode
CONNECTED Node
CONNECTED Node
CONNECTED Node
CONNECTED Node
CONNECTED Node
CHILD CONNECTED parent: Scene child: AutoLayoutNode
CHILD CONNECTED parent: AutoLayoutNode child: Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
CHILD CONNECTED parent: AutoLayoutNode child: Node
```

I may have an error in some code that consumes the `WithChildren` feature, due to load order differences, but that's a different topic.

At least now the callbacks are firing in all the cases in a way that is _almost_ on par with how/when `connectedCallback` and `disconnectedCallback` fire (f.e. `childConnectedCallback`s fire one-to-one with `connectedCallback` at the same time (save for being a microtask apart).

If the engine was had this implemented, it'd be easy: fire the `connectedCallback` (if any) of an element synchronously, then fire the `childConnectedCallback` (if any) of the element's parent synchronously. Boom, done! Super easy! Similarly, I bet it would be easy to add this feature into a Custom Element polyfill.

So, I've gotta see if I can trigger the `childConnectedCallback`s in a way that they match the `connectedCallback` behavior as closely as possible, namely that in `customElements.define` the calls need to be synchronous. I'd expect to see the interwoven console.log output like the fir output example.

I bet I can achieve this with another `customElement.define` patch, though it is a little funky that it'll live outside of my `WithChildren` class. At least it'll be in the same module so the code itself will be logically co-located. I'll post back to https://github.com/w3c/webcomponents/issues/787 once I have that version working...

-- 
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/790#issuecomment-461112930