-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Named slot won't render #7817
Named slot won't render #7817
Comments
There's definitely something weird going on. I added a log to the functional component's render function to inspect the slots that are received: The weird thing is that it's rendered twice (can be explained for itself), but once it receives the slot as "namedSlot", and once as "default", even though the setup is the same. |
I'm afraid not render it is right. |
@gebilaoxiong I'm not sure that test case applies to the situation we have here, can you elaborate? The test case you linked to incorporates one functional component passing slot content to another. That's a different situation that ours in this issue. |
@LinusBorg I think the difference in understanding is on the template of CompB const CompB = {
props: ['state'],
components: {
CompA
},
template: `
<div>
<comp-a>
<slot name="slotA"></slot>
{{ state.prop }}
</comp-a>
</div>
`
}; When CompB is rendered, it generates a structure similar to the follow vnode: <div>
<comp-a>
<span slot="slotA">
THIS TEXT SHOULD RENDER
</span>
{{ state.prop }}
</comp-a>
</div> When CompA is rendered, the slots is: {
slotA: [Vnode], // span element
default: [Vnode] // state.prop
} so I think not render it is right. |
Perhaps the Maybe you're right |
This is a subtle edge case caused when a stateful component triggers a self re-render, which reuses cached slot nodes. The cached slot nodes, if returned from a functional render fn, gets the fnContext property which causes subsequent slot resolving to not function properly. To fix this, nodes returned from functional components need to be cloned before getting assigned fnContext. fix vuejs#7817
This is a subtle edge case caused when a stateful component triggers a self re-render, which reuses cached slot nodes. The cached slot nodes, if returned from a functional render fn, gets the fnContext property which causes subsequent slot resolving to not function properly. To fix this, nodes returned from functional components need to be cloned before getting assigned fnContext. fix vuejs#7817
Version
2.5.15
Reproduction link
https://jsfiddle.net/hirokiosame/dronjdzm/63/
Steps to reproduce
The jsfiddle link reproduces the issue but it's a pretty intricate combination that reproduces it.
Removing the
slot="namedSlot
from thediv
and wrapping it with<template slot="namedSlot">
, orremoving the usage of the functional component
noOp, or disabling reactivity via changing
undefinedto
false` on L20 or removing the dependency on L9 will fix the issue.What is expected?
For the named slot to render. In the case of the reproduction, the "THIS TEXT SHOULD RENDER" text.
What is actually happening?
The named slot is not rendering.
The text was updated successfully, but these errors were encountered: