Lwc: Support insertion of lwc element inside a node marked as lwc:dom="manual"

Created on 29 Jan 2019  路  4Comments  路  Source: salesforce/lwc

Description

lwc:dom="manual" currently currently expects that new nodes being inserted are regular html elements. It is not designed to accept another LWC element.
There are assumptions in the faux-shadow implementation where we assume that root element's are not in the subtree of another root element.
One such example which caused an issue with OwnerKey calculation is described here https://github.com/salesforce/lwc/pull/1018

An example scenario:

<lwc-root-component-1>
  <div aura:dom="manual">
     <!-- Following node is manually injected -->
     <aura-component-a>
           <lwc-root-component-2>
           </lwc-root-component-2>
     </aura-component-a> 
  </div> 
</lwc-root-component-1>

Most helpful comment

Everything is mostly ready @ravijayaramappa did all the work. We just need to switch the implementation. Ravi to add more details

All 4 comments

The main situation here is that if you have a dynamic LWC inside another LWC, and both of them are using the mutation observer for aria, or just because they both use lwc:dom=manual, then both observers will pick up the insertion, and try to own them (is it deterministic?). In order to solve this, we should make the observer to stop observing anything inside another lwc instance, which is not trivial. /cc @davidturissini since we talked about this case in the past.

@caridy Would you have an update on this? This is still needed for component component drag-and-drop in Communities builder as per our discussion. Thanks! FYI @tedconn @k-j-kim

Everything is mostly ready @ravijayaramappa did all the work. We just need to switch the implementation. Ravi to add more details

The foundation work required for solving this issue was to patch the behavior of MutationObserver. This has been done https://github.com/salesforce/lwc/pull/1046. The internal implementation in engine is still running with the native unpatched MutationObserver. Switching that to use the patched MO should fix the issue, theoretically. We are targeting to do make that change in early 222.

Was this page helpful?
0 / 5 - 0 ratings