Inconsistent disconnected/connectedCallback behavior when duplicate slot name is used across lwc:if/lwc:elseif/lwc:else branches

[jmsjtu]

Description

Native shadow, synthetic shadow and light DOM produce inconsistent behavior when duplicate <slot> names are used across lwc:if, lwc:elseif , and lwc:else branches.

This mostly applies to disconnectedCallback but in native shadow the connectedCallback is also affected.

Below are examples of the inconsistencies for the given component:

<template>
    <div lwc:if={show}>
        <slot></slot>
    </div>
    <div lwc:elseif={showOther}>
        <slot></slot>
    </div>
    <div lwc:else>
        <slot></slot>
    </div>
</template>

Synthetic shadow:

• Native lifecycle disabled

  • The slotted component fails to unmount and throws an error stating the element being removed is not a child of the parent.

• Native lifecycle enabled

  • The slotted component successfully unmounts but still produces the same error as ☝️

Light DOM

• Native lifecycle disabled

  • The slotted components never unmount but successfully mount.
    • After refactor: fix light dom slots for fragments #3824 is merged, the newly mounted component will immediately be unmounted.

• Native lifecycle enabled

  • The slotted components are successfully mounted but are immediately unmounted.

Native shadow

An example can be found here, for both native and synthetic lifecycle the components are only mounted a single time and are never unmounted/remounted.

• This is the only place connectedCallback is affected.

Possible Causes

In debugging the <slot> behavior, I believe the issue may be related to the fact that the VNodes representing each <slot> (named or default) generated in the slot API are shared across lwc:if branches.

By nature of using fragments, the dynamic diffing algo causes <slot> content to be mounted before unmounting.

Since the mounting occurs before unmounting and <slot> VNode references are shared across branches, reference to the previous <slot> VM and element are lost prior to unmounting.

This may be causing the discrepancy we're observing.

[jmsjtu]

Upon further investigation it looks like native shadow does not attempt to unmount the slotted content because the vnode containing the slot has no children.

The invocation to the slot API that generates the slot vnode does not have a slotset, which is intentional for native shadow.

We'll need to consolidate the behavior between synthetic and native shadow.