Different behavior with slot vs Astro.slots.render

[ido-pluto]

What version of astro are you using?

2.4.4

Are you using an SSR adapter? If so, which one?

node

What package manager are you using?

npm

What operating system are you using?

Mac

What browser are you using?

Firefox

Describe the Bug

When using the <slot/> syntax and rendering the same component twice, the slot content will be empty.
Not happening when doing with Astro.slots.render

Link to Minimal Reproducible Example

https://codesandbox.io/p/sandbox/priceless-solomon-sxv6r4?on=codesandbox&file=%2Fsrc%2Fcomponents%2FCardContainer.astro%3A1%2C1

Participation

• I am willing to submit a pull request for this issue.

[JerryWu1234]

let me take a look

[JerryWu1234]

@ido-pluto you should add a await for Astro.slots.render

[lilnasy]

I don't see Astro.slots being used anywhere in the repro.

[ido-pluto]

I created a new repo for this:
https://github.com/ido-pluto/astro-render-issue/tree/main

It seems like in Astro version 3, the issue changed form: instead of empty slots, all the slot renders are the same

[lilnasy]

It does render the same random number each time you call slots.render() but that's probably because the component in the slot has already run before it becomes a slot. To make it render uniquely each time, you can turn it into a function.

<RenderMulti count={10}>
	{() => <RandomCard/>}
</RenderMulti>

Does that work for you?

[ido-pluto]

This is working, but it is not the expected behaviour when I want to rerender a slot.
I need to make a special agistment to every nested slot there is.

I need this functionality for a framework I built for Astro that uses this for input validation when I want to render the same thing twice and It will have 2 two different outputs.

I think it still is performant without cache, because if someone wants to render twice, he expects a different output, if not, why not just store the output yourself in a variable?

[lilnasy]

From looking at the compiler output, I would expect that behavior as well. This is probably a bug, I'll take a look.