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.

Sign up for GitHub

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

feat: allow skip hydration for LWR islands #5016

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

feat: allow skip hydration for LWR islands #5016

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions packages/@lwc/engine-core/src/framework/hydration.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -368,6 +368,10 @@ function hydrateCustomElement(
vnode: VCustomElement,
renderer: RendererAPI
): Node | null {
if (elm.hasAttribute('data-lwc-skip-hydrate')) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if (elm.hasAttribute('data-lwc-skip-hydrate')) {
if (renderer.hasAttribute(elm, 'data-lwc-skip-hydrate')) {

This is our convention for abstracting differences between engine-dom and engine-server.

return elm;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

This skips hydration but I'm not sure what happens if the component is updated afterwards.

For example, if the parent has an update that would normally trigger VDOM diffing which would affect the child (e.g. removing it, passing in a new prop, etc.), LWC is not aware of the child, and rendering/callbacks will not be invoked.

Ideally we should have tests in test-hydration to verify this. It might work as-is (the element is just treated opaquely), but I'm not sure.

The custom element tag name may also not be defined, which could cause potential issues if other code is able to "hijack" it – e.g. someone injects code that does customElements.define('lightning-button', ...). Not sure if this is a legitimate attack vector but it's at least unexpected.

const { validationOptOut } = vnode.ctor;
const shouldValidateAttr = getValidationPredicate(elm, renderer, validationOptOut);

Expand Down
Loading