fix(scoped): fixes for <slot /> and slotted nodes

[johnjenkins]

What is the current behavior?

A bunch of bugs related to scoped: true

GitHub Issue Number:

• Fixes: bug: ::slotted(...) selector not working appropriately in scoped: true component #6081
• Fixes: bug: scoped: true / SSR components incorrectly resolve <slot /> during first render #6080
• Fixes: bug: scoped: true SSR hydrated components get duplicated <style> tags #6088

What is the new behavior?

All attached bugs have been fixed combined with a bunch of refactoring (see below for in-depth reasoning).

Documentation

Does this introduce a breaking change?

• Yes
• No

Testing

• New unit tests have been added for scoped slot classes addition and removal.
• New e2e tests have been added to check for correct SSR slot / vdom resolution and duplicate style tags.
• New wdio tests have been tweaked to check of ::slotted(...) selector specificity and making sure slotted nodes do not receive scoped classes.

Other information

TL version

Refactored a bunch of internals in vdom-render.ts

Removed updateElementScopeIds() & findScopeIds() (in-favour of new addRemoveSlotScopedClass())

These methods combined would (too regularly) loop through an entire component tree adding scoped class variants (internal (sc-...), slot (internal + ...-s), and host (internal + ...-h)).

This behaviour is incorrect for a number of reasons:

Children component internals receiving parent scoped class

Given an internal setup like:

// cmp-b
<div class="internal"><slot /></div>

// cmp-a
<cmp-b><slot /><cmp-b>

cmp-bs internal div would receive the internal scope class sc-cmp-a - when it should not as it's not owned by cmp-a in any way.

All component internals receiving the scoped slot class

The scoped slot class (e.g. sc-cmp-a-s) is a hook to use with ::slotted(...) type selectors. Currently it can be applied to the entire parent tree:

<cmp-a class="sc-cmp-a-s ...">
  <div class="sc-cmp-a-s ...">
    <div class="sc-cmp-a-s ...">
      <slot />
  ...

This is incorrect - only the element surrounding the slot should have the class. The result is that ::slotted(...) selectors are applied too liberally.

Scope classes being applied to slotted elements

At present scoped classes apply to slotted elements (elements coming from outside of the component internals). This is incorrect as slotted elements are not 'owned' by the component and results in the behaviour in #6081.

New behaviour

All internal scoped classes are appropriately managed as elements are created. To manage the appropriate scoped slot class, as <slot /> nodes move around the new addRemoveSlotScopedClass() adds / removes the class.

Refactored updateFallbackSlotVisibility()

updateFallbackSlotVisibility() seemed unnecessarily opaque and unreliable. Much of the logic for slot & slotted nodes are managed quite succinctly within dom-extras.ts so I reused it.
As part of that process I moved all shared slot polyfill logic into a new slot-polyfill-utils.ts file.

Tweaks to isSameVnode()

isSameVnode would intentionally not resolve <slot /> / <slot-fb /> nodes during SSR, forcing them to be reconstructed on the client. This had the side-effect of incorrectly resolving the overall VDOM in some instances (#6080).
I've made it so a combination of changes to client-hydrate.ts & mock-doc/element.ts now provide everything needed during SSR - these nodes no longer need to be reconstructed.

[christian-bromann]

LGTM 👍

[christian-bromann]

@johnjenkins it seems like the WebdriverIO test fail for legit reasons.

[johnjenkins]

@christian-bromann ty - test snapshots were incorrect. Updated now.