⚠️ No Changeset found

Latest commit: 0af8eda

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

_{tachometer-reporter-action v2 for Benchmarks}

Good start.

In addition to your notes above, also just want to add these for discussion:

• This effectively makes the CE instance required, since it's relying on arbitrary user code doing this.dispatchEvent on the instance... I know we want to suspend constraints on an interface-only ElementRenderer while exploring, but this seems like a fundamental decision
• This would not be compatible with loading an alternate DOM shim, since the instance would be disconnected and have no parent; to make it compatible, we'd need to do parent.appendChild(instance) and have the shim do the __eventTargetParent hookup, but it might be problematic to just randomly "append" into the parent if that's not actually where it goes (due to the desire to skip built-ins)

Wonder if there's an alternative that would be more compatible with bring-your-own-shim and keeping the ElementRenderer just an interface where instead of requiring the instance to hook up the fake parent, we instead:

• Add ElementRenderer:dispatchEvent (which in ours will just call instance.dispatchEvent()
• Add a patch of dispatchEvent on whatever Element.prototype exists (either our dom shim, which would just have Element extend EventTarget, or a real DOM shim like jsdom, which would have a more correct implementation)
• Our patch would super to the existing dispatchEvent, and then if it should bubble AND there's no this.parentNode (which is always the case in our DOM shim, and would be the case when using jsdom and you go up and hit a LitElementRenderer instance), then look in the (somehow-made-accessible) open custom elements stack and dispatch to the next element up.

It seems like that might avoid punting on ElementRenderer just yet.

We of course (maybe as part of this), should try running with a full DOM shim to make sure even the basic stuff works there, and specifically that event dispatch would work.

Pinging @nicholasrice from FAST to take a look. My cursory glance leads to me to think this will work for us as well.

I am definitely in support of exposing dispatchEvent. The largest use-case for us will be context and dependency-injection APIs. Our DI infrastructure already is implemented using events on the client, and we have a context-like feature that could be implemented on the server using events. We also have plans to implement general-purpose context APIs, which would obviously benefit as well.

• Can we have an event path of just the custom elements without materializing the built-ins that would be on the path with a > full DOM structure? This seems ok if the only event patterns we support are for cross-custom-element communication, ie context.

I think this constraint is suitable for our implementations and the majority of our components. It seems in-line with other code we have that no-ops operations that would provide references to native elements, such as ref directives, slotted element inspection, etc.

Superseded by #4755