[bug]: Prop validation fails for child components with required props passed from parents

[alionazherdetska]

Depends on: #6471

Description:

Currently, when post-menu is used as a child component (e.g., within post-language-switch), the label prop validation fail in Nextjs integration package:

Current Workaround:

Implemented in #6471 - using requestAnimationFrame() to defer validation in post-menu.

Task:

• Investigate and implement a proper solution for validation timing in nested components. This may involve:

1. Enhancing validation utilities (checkRequiredAndType, etc.) to be aware of parent-child component lifecycle
2. Adding an option to defer validation for nested components

• Remove requestAnimationFrame() workaround from post-menu

Affected Components:
Potentially any component with required props that may be used as a child component.

[gfellerph]

Update the property checker function to check if the component is rendered inside a shadow dom. If that is the case, wait until the parent component is defined with the whenDefined (https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/whenDefined). Alternatively, use the stencil provided lifecycle events https://stenciljs.com/docs/api#componentonready to detect readyness of the parent and delay the check until the parent is ready.

[oliverschuerch]

Comparing SSR and CSR component creation

SSR	CSR

---

This is an issue, which affects all of our components, if they are used as SSR components.
Assume the following:

In a SSR enviroment, the server renders the components and sends the result to the client. So, what arrives on the client side (before hydration happens), is the following:

This is an issue, which affects all of our components, if they are used as SSR components.
Assume the following:

In a SSR enviroment, the server renders the components and sends the result to the client. So, what arrives on the client (before hydration happens), is more or less the following:

```html
<post-language-switch
  caption="Change the language"
  description="The currently selected language is English."
  variant="menu"
  data-hydrated
>
  <template shadowrootmode="open">
    <style>/* ... */</style>
    <post-menu-trigger
      for="pHNjeoTauodA"
      tab-index="-1"
      data-hydrated
    >
      <!-- button with content -->
    </post-menu-trigger>
    <post-menu
      id="pHNjeoTauodA"
      class="post-language-switch-dropdown-container"
      data-hydrated
    >
      <template shadowrootmode="open">
        <style>/* ... */</style>
        <post-popovercontainer
          popover="auto"
          data-hydrated
        >
          <div class="popover-content">
            <div part="menu">
              <slot name="header"></slot>
              <slot ></slot>
            </div>
          </div>
        </post-popovercontainer>
      </template>
      <slot></slot>
    </post-menu>
  </template>
  <!-- Language options -->
</post-language-switch>

As you clearly can see, <post-menu>, which in a CSR scenario would only be rendered through JS as a child of <post-language-switch>, is directly visible in the DOM (sure it is inside a <template> tag, but that does not seem to make a difference).
This has the strange drawback, that it can be hydrated by the browser, as soon as JS has been initialized and the component has been lazy-loaded. It does not need to wait für <post-language-switch> to render first.
In fact, if it renders before <post-language-switch>, it will automatically be rerendered a second time, within the parent render function, leading to unwanted rerenderings on init.

[oliverschuerch]

Latest finding:
If we set @Prop({ reflect: true }) the value specified on the parent component gets rendered already on the server, which means, the component can be initialized whenever it is ready, without throwing a console error.