Lwc: Define manual DOM manipulation in the template

[caridy]

Sometimes, components need to insert d3 and other markup that can't be produced by describing it in the template. In this case, we should allow templates to signal that the entire template, or at least an element in the template is supposed to be a portal to show 3rd party content.

[diervo]

Why?

[caridy]

how to use d3 inside LWC?

[diervo]

All DOM APIs should work no?

[caridy]

We have some restrictions in place, and we were planning to add more:

• https://github.com/salesforce/lwc/blob/master/packages/lwc-engine/src/framework/restrictions.ts#L83-L93

• https://github.com/salesforce/lwc/blob/master/packages/lwc-engine/src/framework/restrictions.ts#L15-L31

[caridy]

Revamping this since we are having some issues with retargeting, e.g. : https://github.com/salesforce/lwc/pull/739

[diervo]

Well the portal usecase is specially important for CSS since we are workarounding the retargeting for now.

[caridy]

The concept is not really about a portal, but about manipulation of dom elements inside the template via imperative API. We have implemented a new directive:

<template>
    <div lwc:dom="manual"></div>
</template>

where only leaf nodes can have that directive in the template, and only those elements could be manipulated by appending or removing children to them. Those new elements inserted there will be adopted by the shadow, which means they will behave just like anything else from the actual template.

Notes:

• slots can't be marked with this directive.

Let's keep this open until after we make the current warning a hard error.

[caridy]

maybe solved by https://github.com/salesforce/lwc/pull/1193?

[caridy]

@ekashida can you confirm that his is now done?

[ekashida]

@caridy From what I can tell, this issue is to track the lwc:dom="manual" feature, which has already been implemented. I think you commented above that we should keep this issue open until we convert all the error logging into actual exceptions.