Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abstracting the Custom Element Infrastructure out of Core Package #2799

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

caridy
Copy link
Contributor

@caridy caridy commented Apr 21, 2022

Details

As of today, core package understands the concept of custom elements, and DOM APIs to deal with custom elements. This PR eliminates that in favor of moving that logic into the DOM Package. The reason for this to happen is that it will provide greater flexibility to introduce the concept of custom elements for certain distributions without affecting core.

Does this pull request introduce a breaking change?

  • ✅ No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

  • ✅ No, it does not introduce an observable change.

Note: it does introduce two methods available on any custom element that is not globally registered. This two methods are $connectedCallback$ and $disconnectedCallback$. We could hide them out via a weakmap, but we can discuss that later on.

GUS work item

@caridy caridy marked this pull request as draft April 21, 2022 22:52
linkNodeToShadow(elm, owner);
vnode.elm = elm;
vnode.vm = vm;

if (vm) {
allocateChildren(vnode, vm);
} else if (vnode.ctor !== UpgradableConstructor) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is another observable difference, because core doesn't care anymore, you might simply rely on a globally defined element while resolving to something completely unrelated. This makes is easier to eventually introduce the concept of external/global custom elements into templates. Eventually the ctor value can be NULL

@caridy caridy force-pushed the caridy/abstracting-core-ce-infra branch 2 times, most recently from a7bd9f1 to 0197a56 Compare May 4, 2022 04:14
refactor(engine): more simplification on the registration logic
@caridy caridy force-pushed the caridy/abstracting-core-ce-infra branch from 0197a56 to 2df12cf Compare May 4, 2022 04:24
Copy link
Contributor

@nolanlawson nolanlawson left a comment

Choose a reason for hiding this comment

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

The reason the test is failing is because the renderedCallback is being called twice for a hydrated element. There is a test that checks that it's only called once, and with the proper timing:

expect(p.textContent).toBe('renderedCallback:false');
return Promise.resolve().then(() => {
expect(p.textContent).toBe('renderedCallback:true');
});

The easiest way (I've found) to run this test is to delete all the other hydration test files and run yarn hydration:start.

I understand the goal this PR is trying to accomplish (refactoring DOM-specific logic outside of @lwc/engine-core), but I think we'd need to figure out why the tests are breaking before we merge this.

@@ -31,6 +31,7 @@ export function createContextProvider(adapter: WireAdapterConstructor) {
}
adapterContextToken = guid();
setAdapterToken(adapter, adapterContextToken);
// [TODO #2813]: this doesn't work on IE11
Copy link
Contributor

Choose a reason for hiding this comment

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

Unrelated to this PR. I think we can do the investigation in #2813 .

@nolanlawson
Copy link
Contributor

@caridy Are you still planning to merge this PR? Can we close it for now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants