Skip to content
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

RFC: lwc:dom directive reform #17

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

caridy
Copy link
Contributor

@caridy caridy commented Oct 29, 2019

WIP

Rendered

</div>

<h1>Introducing new feature (for leaf element only):</h1>
<div lwc:dom="synthetic-portal"></div>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposal doesn't provide details about syntehtic-portal? What are the intended use cases, and the expected behviors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:) it is WIP, you are not supposed to be reviewing it yet... jajaja... let me finish this today.


1. The existing restriction that only leaf elements can be marked with `lwc:dom="manual"` is limiting. There are valid use-cases that requires a mix of elements generated from a template plus manually inserted elements, one of them is the use of a graph library that can connect elements (visually) where the elements are controlled via the template declarative mechanism, while the edges are manually generated and inserted by a 3rd party library.

2. Legacy systems, specifically flexipages in Aura applications, are in needs to support rendering legacy DOM structures that are not suitable, or were not designed, to work inside a `ShadowRoot` instance. In such cases, it is imperative that from the perspective of those elements, they should behave as inserted in the document.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is imperative that from the perspective of those elements, they should behave as inserted in the document.

What are concrete cases where this is needed?

@ghost
Copy link

ghost commented Nov 15, 2019

@caridy Perhaps it's an appropriate time to discuss the ability to insert a component in a different place in the dom - specifically, moving it to be a child up the tree (eg. under document.body for say a global modal, and under a tab for a scoped modal).

This wouldn't be needed if we had say browser's level blockingElement (ie. everything but the element is inert) and top layer, but that is unlikely to come any time soon

If we are ok with this in principle (the component created/rendered someplace else but still fully managed), there are a few ways that this could be achieved, purely for illustration purposes here's an example of one:

<body>
  <!-- Defines the portal -->
 <lightning-portal lwc:portal="modal"></lightning-portal>
 <x-foo> 
   <y-foo>
       <lighthing-dialog ...>
           <!-- Insertion/content mode - portal, portal name - "modal" -->
           <div lwc:dom="portal" lwc:portal-name="modal"> 
             ...
             <slot name="content"></slot>
             <slot name="footer"></slot> 
             ...
          </div>
       </lightning-dialog>
   </y-foo>
 </x-foo>
</body>

This should definitely be gated.

What are your thoughts on this ?

@jbenallen
Copy link

What is the state of this proposal? @caridy

@gregwhitworth
Copy link

@pmdartus @caridy hey - we have a WI open on this. Are we going to complete this PR? If not can you please close this out.

@pmdartus
Copy link
Member

Correct if I get the intention of the proposal wrong @caridy.

I don't think we want to pursue this proposal (at least in the current state). One of the major drivers of this proposal is to integrate Aura component in LWC as we are migrating larger chunks of the application. I see in the Light DOM proposal a way to integrate Aura components in LWC without running into shadow DOM related issues.

@pmdartus pmdartus added the draft label Oct 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants