-
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
feat(lightning-element): expose hostElement property #4259
feat(lightning-element): expose hostElement property #4259
Conversation
const isRenderLight = vm.renderMode === RenderMode.Light; | ||
|
||
if (isRenderLight) { | ||
return vm.elm; |
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'm pretty sure you can just return vm.elm
everywhere, without regard to light/shadow mode.
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.
Thanks a bunch for this PR! 😄
This LGTM, although we want to do some internal bikeshedding first before we decide on the name. It may change from elementSelf
before it gets merged.
@@ -542,6 +543,11 @@ function warnIfInvokedDuringConstruction(vm: VM, methodOrPropName: string) { | |||
return vm.shadowRoot; | |||
}, | |||
|
|||
get elementSelf(): Node | undefined { |
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.
get elementSelf(): Node | undefined { | |
get elementSelf(): Element { |
I don't see how this could possibly be undefined or a Node
. The vm.elm
type may not be strict enough, so you might have to cast 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.
We can also put a sanity check in here:
if (process.env.NODE_ENV !== 'production') {
assert.isTrue(!isUndefined(vm.elm) && vm.elm instanceof Element, `this.elementSelf should be an Element, found: ${vm.elm}`)
}
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.
nit: just check vm.elm instanceof Element
because undefined instanceof Element
works just fine.
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.
TIL! Thanks.
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.
Thanks for your feedback
@@ -194,6 +194,7 @@ export interface LightningElement extends HTMLElementTheGoodParts, AccessibleEle | |||
constructor: LightningElementConstructor; | |||
template: ShadowRoot | null; | |||
refs: RefNodes | undefined; | |||
elementSelf: Node | undefined; |
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.
elementSelf: Node | undefined; | |
elementSelf: Element; |
See below.
c5faf8b
to
6b7ece5
Compare
|
||
if (process.env.NODE_ENV !== 'production') { | ||
if (isFalse(vm.elm instanceof Element)) { | ||
logError(`this.elementSelf should be an Element, found: ${vm.elm}`); |
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 think we should do assert.false
here instead.
Historically we do try to avoid throwing dev-only errors, but in this case I don't think it applies, because this is an invariant in the framework itself. If we are returning something other than an Element
here, then something has gone horribly wrong and we need to fix 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.
sure, let me have a look on it
2fe2853
to
98d6d13
Compare
Based on #4275 it looks like we are going to go with |
I also went ahead and made I don't think this is really needed on the server, so we should proactively block it. |
/nucleus test |
/nucleus ignore -- reason 'downstream flaky test' |
❌ Error Parsing CommandMissing required argument: reason
|
/nucleus ignore --reason 'downstream flaky test' |
Thank you! |
Thanks you so much @nolanlawson |
Details
Fixes #4219
Related to issue 4219 for the following feature:
Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?
GUS work item