-
Notifications
You must be signed in to change notification settings - Fork 400
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
fix(engine): close #849 by implementing move hook #852
Conversation
Benchmark resultsBase commit: lwc-engine-benchmark
|
@@ -117,8 +117,7 @@ export class SyntheticShadowRoot extends DocumentFragment implements ShadowRoot | |||
return getHost(this).baseURI; | |||
} | |||
get isConnected(this: SyntheticShadowRootInterface) { | |||
// @ts-ignore remove this after upgrading ts 3.x | |||
return getHost(this).isConnected; | |||
return (compareDocumentPosition.call(document, getHost(this)) & DOCUMENT_POSITION_CONTAINED_BY) !== 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this changing? Is this relevant to the PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, probably something that should have done in another PR, but there are failures on the accessibility lib that we have implemented for lightning namespace that is failing because this.template.isConnected is always undefined or false, that's because it is not implemented everywhere and we are not polyfilling it. This is the proper implementation that works across the board for shadows
expect(elm.shadowRoot.textContent).toBe('5431'); | ||
elm.sort('ASC'); | ||
return Promise.resolve().then(() => { | ||
expect(elm.shadowRoot.textContent).toBe('1345'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do we see before this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was throwing during the first rehydration because it was trying to repatch the element while moving it from one position to another.
@@ -34,7 +34,7 @@ export interface WireHash { | |||
export interface RegisterDecoratorMeta { | |||
readonly publicMethods?: string[]; | |||
readonly publicProps?: PropsDef; | |||
readonly track?: string[]; | |||
readonly track?: TrackDef; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a mistake, diego was passing the right value from compiler, but we were typing that incorrectly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@davidturissini you should re-review this once you are back (and the retargeting as well), but need to merge it to unblock LGC. |
Details
We were using the
insert
hook for the cases when we just move an existing node up or down in the children collection. This was causing the node to be re-patched, which can produces unpredictable results.Does this PR introduce a breaking change?