Lwc: LWC API for getting the owner (host) of a DOM node

Created on 26 Sep 2018  路  6Comments  路  Source: salesforce/lwc

LWC should expose an API where, given a DOM node, the owner of that DOM node can be returned:

function getNodeOwner(node: Node): HTMLElement | undefined

This is needed for Locker to provide proper access checks based on the owner of a given node since template.host is not available.

Most helpful comment

Let me put down what Caridy had suggested so that we are all on the same page:

Summary:
```so, IF you wish to implement this, the model is actually very simple
it is the same model that we use internally in the synethtic shadow DOM implementation that we have
you traverse the DOM via proxies, using the dot notation, until you can鈥檛 traverse it anymore or until you find the element that you own/know
if you traverse up, and you receive null, what does it means? it means that you have hit a boundary with the dot notation
at this point, you rely on low-level high-privilege APIs to by pass the LWC restrictions
this model works well for synthetic and native shadow

Logic in steps
  1. Start with an element(wrapped in traverse-proxy or native shadow dom(SD))
  2. Traverse up using .parentNode, that means SD semantics are in place. Eventually you will find either:
    a) null value for parentNode, or
    b) an element (or a wrapped version of an element today) of the element that you know about (e.g. the aura鈥檚 signed element from interop)
  3. if you find null, you have two choices:
    a) if this is native SD, and the element is an instance of ShadowRoot, then you can use ShadowRoot.prototype.host getter to get the actual host, bypassing the patching/proxies of this property
    b) if this is synthetic SD, then you can invoke Node.prototype.parentNode getter, which will let you bypass the patching/proxies of this property
    ```

All 6 comments

Since the logic is similar to event retargeting, could we just reuse the getNodeOwner logic from that system?

Also, where would be an appropriate place to expose this API? Looking at how Locker consumes the APIs, I'm guessing it would need to be exported from main.ts. Is that correct?

No, I still think this is not necessary for them to know the ownership. I have explained the details to @ravijayaramappa on how they can do this with and without native shadow dom in place.

Let me put down what Caridy had suggested so that we are all on the same page:

Summary:
```so, IF you wish to implement this, the model is actually very simple
it is the same model that we use internally in the synethtic shadow DOM implementation that we have
you traverse the DOM via proxies, using the dot notation, until you can鈥檛 traverse it anymore or until you find the element that you own/know
if you traverse up, and you receive null, what does it means? it means that you have hit a boundary with the dot notation
at this point, you rely on low-level high-privilege APIs to by pass the LWC restrictions
this model works well for synthetic and native shadow

Logic in steps
  1. Start with an element(wrapped in traverse-proxy or native shadow dom(SD))
  2. Traverse up using .parentNode, that means SD semantics are in place. Eventually you will find either:
    a) null value for parentNode, or
    b) an element (or a wrapped version of an element today) of the element that you know about (e.g. the aura鈥檚 signed element from interop)
  3. if you find null, you have two choices:
    a) if this is native SD, and the element is an instance of ShadowRoot, then you can use ShadowRoot.prototype.host getter to get the actual host, bypassing the patching/proxies of this property
    b) if this is synthetic SD, then you can invoke Node.prototype.parentNode getter, which will let you bypass the patching/proxies of this property
    ```

@caridy @jye-sf Can LWC provide such an api instead of Locker writing this custom logic?
Benefits:

  1. This is LWC specific logic, makes sense for it to be in LWC rather than Locker code base
  2. LWC can update the logic and make sure it always works, instead of co-ordinating releases with locker

I think this is not longer an issue, @ravijayaramappa can you confirm and close?

@caridy Yeah, this is not required. I don't have permission to close the issue.

Was this page helpful?
0 / 5 - 0 ratings