-
Notifications
You must be signed in to change notification settings - Fork 403
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(ssr): normalize class in child attrs #4953
fix(ssr): normalize class in child attrs #4953
Conversation
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.
Looking great so far, just a small issue with ctx.import()
and a request for a new test. Thanks a bunch! 🥇
<x-child class="button__icon"> | ||
<template shadowrootmode="open"> | ||
</template> | ||
</x-child> |
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.
Another case we should cover here for safety: dynamic components (lwc:component
). These technically go down a different code path (LwcComponent.ts
), although you should still hit it since it will call into getChildAttrsOrProps
. As mentioned elsewhere though, I think this should be a separate standalone fixture.
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 hit an interesting behavior when first doing a single fixture:
If I imported 'x/child' and passed its constructor into lwc:component while also using it directly as <x-child></x-child>
.
__SYMBOL__GENERATE_MARKUP is not defined
Is this issue known? Doesn't seem convered by the existing fixtures.
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.
Seems like an unrelated error!
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.
Opened #4958
…sr-child-class-binding
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! Thanks 🌞
/nucleus test |
Details
There might be a better way to do this, but it could be enough for now.
I updated the tests added in #4931 to cover this case. It still doesn't fix any expected failures but reduces the diff further:
Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?
Template class binding should mostly work for child components now.
GUS work item