-
Notifications
You must be signed in to change notification settings - Fork 393
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: spread not being reactive #3709
Conversation
/nucleus ignore -m "lwc-platform snapshot tests are failing" |
@@ -594,6 +594,12 @@ function transform(codeGen: CodeGen): t.Expression { | |||
data.push(codeGen.genRef(ref)); | |||
} | |||
|
|||
// Spread |
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.
Follow existing comment format?
// Spread | |
// Properties: lwc:spread directive |
@@ -594,6 +594,12 @@ function transform(codeGen: CodeGen): t.Expression { | |||
data.push(codeGen.genRef(ref)); | |||
} | |||
|
|||
// Spread | |||
if (spread) { |
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.
Question on the ordering here, should an innerHTML
coming in through lwc:spread
override the lwc:inner-html
directive?
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.
Good question! It should override that HTML just like it overrides all other properties. Added a test for it.
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.
I see we have a test for spread overriding props already:
<x-child class="x-child-overridden" name="lwc" onclick={templateClick} lwc:spread={overriddenProps}></x-child> |
However, this tests onclick
, which I think behaves a bit differently in the compiler compared to standard props. Can we add a test to ensure that spread overrides standard props? (If it doesn't already exist.)
E.g.:
{
foo: 'bar',
...props // where props is { foo: 'baz' }
} // result should be 'baz'
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.
name
in the above example is a regular prop.
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.
Ah, my mistake! Totally missed that.
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 is indeed way simpler than before, love it! Just had one nitpick about tests.
@@ -594,6 +594,12 @@ function transform(codeGen: CodeGen): t.Expression { | |||
data.push(codeGen.genRef(ref)); | |||
} | |||
|
|||
// Spread | |||
if (spread) { |
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.
I see we have a test for spread overriding props already:
<x-child class="x-child-overridden" name="lwc" onclick={templateClick} lwc:spread={overriddenProps}></x-child> |
However, this tests onclick
, which I think behaves a bit differently in the compiler compared to standard props. Can we add a test to ensure that spread overrides standard props? (If it doesn't already exist.)
E.g.:
{
foo: 'bar',
...props // where props is { foo: 'baz' }
} // result should be 'baz'
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!
Details
lwc:spread
was not reactive when used with @track decorator. The properties within the object were being accessed when patching the element, which is outside of the template reactive observer. This PR moves it to within the render method, which is invoked during template reactive observer. It also makes the code much simpler.Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?
GUS work item