feat: add support for ElementInternals in synthetic shadow

[roxanne-baker]

Details

Removes the existing error when attempting to use attachInternals in synthetic shadow and instead uses a Proxy in synthetic shadow to ensure that the shadow root returns as expected. Error message was also removed for FACE-related callback methods in synthetic shadow.

Existing tests were updated to run in synthetic shadow and new tests added to cover functionality related to other ElementInternals properties not covered by existing tests.

Does this pull request introduce a breaking change?

No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

Yes, it does include an observable change.

ElementInternals/attachInternals and FACE callbacks should now be fully supported in synthetic shadow instead of throwing errors.

GUS work item

W-19275967

[salesforce-cla]

Thanks for the contribution! Unfortunately we can't verify the commit author(s): roxanne.baker <r***@s***.com>. One possible solution is to add that email to your GitHub account. Alternatively you can change your commits to another email and force push the change. After getting your commits associated with your GitHub account, refresh the status of this Pull Request.

[roxanne-baker]

without this the stylesheet was removed after the first test, but since it was cached it wouldn't get re-added - meaning that the styles were only actually present for the first test

[wjhsf]

1. In synthetic shadow, can a user do HTMLElement.prototype.attachInternals.call(someComponent) and get access to the real shadow root (not synthetic)? Or do we already guard that?
2. IIRC we wanted this to be an internal-only feature because synthetic shadow is deprecated, right? I think we'll need a compiler flag. Lemme double check.

[roxanne-baker]

1. I didn't explicitly do anything against that but trying it seems to result in an illegal invocation error
2. I think so - I'm not sure where to find a reference for other compiler flags in the code though, could you point me to an example I can use to learn from?

[wjhsf]

const __lwc_component_class_internal = _registerComponent(Test, {
  tmpl: _tmpl,
  sel: "lwc-test",
  apiVersion: 9999999
});

This is the current result of compiling an LWC component. In order to have a compile-time switch for synthetic element internals, we should add an additional property to the object, which should just reflect a boolean set in the compiler options. Because 99% of components will never set the flag, we can avoid unnecessarily increasing file sizes by only setting the property when the compiler flag is true (and setting it to 1 instead of true 📈). Here's where the object is defined:

lwc/packages/@lwc/babel-plugin-component/src/component.ts

Lines 86 to 92 in b6e43be

	t.objectExpression([
	t.objectProperty(t.identifier(TEMPLATE_KEY), templateIdentifier),
	t.objectProperty(t.identifier(COMPONENT_NAME_KEY), componentRegisteredName),
	// It's important that, at this point, we have an APIVersion rather than just a number.
	// The client needs to trust the server that it's providing an actual known API version
	t.objectProperty(t.identifier(API_VERSION_KEY), t.numericLiteral(apiVersion)),
	]),

The flag should be an optional boolean set via @lwc/compiler and piped through the packages to get to where it's needed for compilation. At runtime, you can update the metadata interface definition, then add a helper that you can use in your code.

lwc/packages/@lwc/engine-core/src/framework/component.ts

Lines 23 to 27 in b6e43be

	type ComponentConstructorMetadata = {
	tmpl: Template;
	sel: string;
	apiVersion: APIVersion;
	};

lwc/packages/@lwc/engine-core/src/framework/component.ts

Lines 62 to 64 in b6e43be

	export function getComponentRegisteredName(Ctor: LightningElementConstructor): string | undefined {
	return registeredComponentMap.get(Ctor)?.sel;
	}