-
Notifications
You must be signed in to change notification settings - Fork 25
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
base: master
Are you sure you want to change the base?
Conversation
</div> | ||
|
||
<h1>Introducing new feature (for leaf element only):</h1> | ||
<div lwc:dom="synthetic-portal"></div> |
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.
The proposal doesn't provide details about syntehtic-portal
? What are the intended use cases, and the expected behviors?
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.
:) 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. |
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.
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?
@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 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 ? |
What is the state of this proposal? @caridy |
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. |
WIP
Rendered