Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: add support for ElementInternals in synthetic shadow#5519

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
roxanne-baker wants to merge8 commits intosalesforce:master
base:master
Choose a base branch
Loading
fromroxanne-baker:synthetic-element-internals

Conversation

roxanne-baker
Copy link

@roxanne-bakerroxanne-baker commentedSep 27, 2025
edited
Loading

Details

Removes the existing error when attempting to useattachInternals 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 otherElementInternals 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-claSalesforce CLA
Copy link

Thanks for the contribution! Unfortunately we can't verify the commit author(s): roxanne.baker <r***@s***.com>. One possible solution is toadd that email to your GitHub account. Alternatively you canchange 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-bakerroxanne-baker changed the titlefeat: Add support for ElementInternals in synthetic shadowfeat: add support for ElementInternals in synthetic shadowSep 27, 2025
// Ensure the DOM is in a clean state
document.body.replaceChildren();
document.head.replaceChildren();
window.__lwcResetGlobalStylesheets();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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

Copy link
Contributor

@wjhsfwjhsf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

  1. In synthetic shadow, can a user doHTMLElement.prototype.attachInternals.call(someComponent) and get access to thereal 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-bakerand others added2 commitsSeptember 30, 2025 13:12
…ement.attachInternals/elementInternals/formAssociated/index.spec.jsCo-authored-by: Will Harney <62956339+wjhsf@users.noreply.github.com>
…ement.attachInternals/elementInternals/formAssociated/index.spec.jsCo-authored-by: Will Harney <62956339+wjhsf@users.noreply.github.com>
@roxanne-baker
Copy link
Author

  1. I didn'texplicitly 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
Copy link
Contributor

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 istrue (and setting it to1 instead oftrue 📈). Here's where the object is defined:

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.

typeComponentConstructorMetadata={
tmpl:Template;
sel:string;
apiVersion:APIVersion;
};

exportfunctiongetComponentRegisteredName(Ctor:LightningElementConstructor):string|undefined{
returnregisteredComponentMap.get(Ctor)?.sel;
}

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@ekashidaekashidaekashida left review comments

@wjhsfwjhsfwjhsf left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@roxanne-baker@wjhsf@ekashida

[8]ページ先頭

©2009-2025 Movatter.jp