Nested async components passed as slots are not rendered in SSR

[jimmytsao]

Version

2.6.10

Reproduction link

https://codesandbox.io/s/vue-ssr-nested-async-components-repro-script-ozze7

Steps to reproduce

When the codesandbox starts up, it should run the npm start script. If it doesn't, open a bash terminal and run npm start to see the HTML generated from SSR. You can also take a look at the components in the src folder to see how they are configured.

What is expected?

Expected the HTML for the nested async component (called "SomeComponent") to be rendered during SSR:

<div data-server-rendered="true">
  <div class="Grid">
    <div class="Grid__left">Left
      <div class="SomeComponent">Somecomponent with value: first</div>
    </div>
    <div class="Grid__right">Right
      <div class="SomeComponent">Somecomponent with value: second</div>
    </div>
  </div>
</div>

What is actually happening?

The HTML for the nested async component (called "SomeComponent") is not rendered during SSR. Only the HTML for the outer async component (called "Grid" ) is rendered:

<div data-server-rendered="true">
  <div class="Grid">
    <div class="Grid__left">Left
    </div>
    <div class="Grid__right">Right
    </div>
  </div>
</div>

---

I have an App that is composed of many async components. Some of these components have named slots. I was trying to build a render function that will accept a config object to render these components in various setups (for example, an async component set to a named slot of another async component). I noticed that if I nest async components within another, the HTML for the async component does not render during SSR. The codesandbox is simplified scenario of this

[posva]

It seems to be related to the fact that the slot is a scoped slot so it is lazily used. The problem disappears if the components is directly used or passed as a regular slot.

As a side note though, components that are directly visible in a page should not be lazy loaded as that would be a waste of network requests and things are faster with fewer request. The only exception being the page itself or nested pages. This doesn't invalidate the usage of async components though, as it may depend on a v-if, thus making the lazy loading of two component valuable

[trip-somers]

I have a similar problem that appears to be some kind of a race condition. I'm not sure if it should be a new issue, so I'll start here and describe it.

My app is a multi-page app with a main app.js file that essentially configures the separate pages as async components, so that we don't have to pack hundreds of components into a single app.js file. The result is a pattern counter to what @posva suggested. For example, someone would visit /shipment/12345/edit and the main js file would load normally with the Shipment component loading asynchronously.

The problem I have is that the Shipment component only renders sometimes. It always mounts, as evidenced by 'Shipment component mounted' console logs. When it doesn't render, the DOM where it should be is simply blank. Rendering seems to be more reliable when 'Disable Cache' is checked in dev tools. This makes it seem like a race condition, but I can only imagine what that condition could be.

EDIT: I am not using SSR, so this would appear to be similar but unrelated. If this comment is off-topic as a result or not constructive, you won't hurt my feelings by removing/hiding it.

[endyquang]

I'm seeing this race condition problem too, with Nuxt SSR

Sometime the page is rendered perfectly fine sometime not
The console error says TypeError: Cannot read property 'toLowerCase' of undefined at emptyNodeAt...

My workaround is having a fallback dummy div inside every slot tags
It solves the problem for me but I use a lot of slots in my project

[pi0]

Here is a minimalistic reproduction: https://replit.com/@pi0/vuejsvue10391

Issue seems caused by 781c705. For some reason, for async components isComment is true. Reverting L65 fixes but I guess have to investigate why isComment is true for proper fix. we should check with isAsyncPlaceholder

Update: #11963