exportparts attribute on a shadow host throws error

[brandonferrua]

Description

When using the ::part API with native shadow, in particular part forwarding through exportparts, the LWC engine throws an error:

Unknown public property "exportparts" of element <PRIMITIVE-OVERLAY>. This is likely a typo on the corresponding attribute "exportparts".

Reflecting the attribute on the host gets around this error and I can export the part up the shadow boundary.

Steps to Reproduce

<!-- parent -->
<template>
  <div part="dropdown">
    <a href="" part="label"></a>
    <primitive-overlay exportparts="overlay">
      <slot></slot>
    </primitive-overlay>
  </div>
</template>

<!--child-->
<template>
  <div part="overlay" role="none">
    <slot></slot>
  </div>
</template>

Expected Results

No error is throw, standard API usage

Actual Results

Unknown public property "exportparts" of element <PRIMITIVE-OVERLAY>. This is likely a typo on the corresponding attribute "exportparts".

Browsers Affected

N/A

Version

• LWC: 2.20.1

@gonzalocordero @nolanlawson

[nolanlawson]

@brandonferrua I'm confused about this – is this about ::part or about the attribute exportparts above? Does the primitive-overlay component have a property called exportparts?

As I understand it, this error is thrown whenever you try to set a property on a component and that property does not exist. Here is an example (showing expected behavior). The solution is to add @api exportparts to the class for the child component.

[brandonferrua]

it's about exportparts, which is a part of the spec https://drafts.csswg.org/css-shadow-parts/#exportparts-attr.

The reason why I bring it up is per the spec, it can be placed on any element, including the custom element to forward the part attribute up the shadow tree so I can style it from the outside.

For this reason, I was wondering if LWC wanted to allow list/reserve this attribute for use on the shadow host so the author didn't have to remember to add the @api decorator.

[pmdartus]

I was wondering if LWC wanted to allow list/reserve this attribute for use on the shadow host so the author didn't have to remember to add the @api decorator.

Adding a public property called exportparts using @api decorator isn't enough. The component author would also need to reflect the property to the attribute. The part attribute happens to work today because there is an associated property automatically reflecting it to an attribute but it's not the case for exportparts. Note that the usage of the part attribute on a standard element in the template produces a warning.

Overall we need a story to better deal with part and exportparts` attributes in the template.

[git2gus[bot]]

This issue has been linked to a new work item: W-11605544

[nolanlawson]

I think the simplest solution is to treat exportparts as an attribute in the compiler ^.

As it turns out, it's only available as an attribute anyway. Unlike part, there is no property equivalent:

• exportparts
• part
• Element.part