Skip to content

scopedSlots as Function returns only first element from array: res[0] #1757

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

Open
voskresla opened this issue Dec 23, 2020 · 1 comment
Open
Labels

Comments

@voskresla
Copy link
Contributor

Subject of the issue

We can't use code like this:

wrapper = mount(Tag, {
	scopedSlots: {
		myScoped() {
			return [
				<div id="v-slot">Click in this must return 0 in console</div>,
				<div id="v-slot">Click in this must return 1 in console</div>
			]
		}
	}
})

Steps to reproduce

https://gitlab.com/vskrsl/vtu-issue-scopedslots-array

I try to describe more about use case in test file. And example in native vue (instead tsx) how i can solve this.

Expected behaviour

I expected that all slots will be rendered not only first.

Actual behaviour

Because we have check on string https://github.com/vuejs/vue-test-utils/blob/dev/packages/create-instance/create-scoped-slots.js#L126 we got only first element of scopedSlots array (res[0])

Possible Solution

Does we realy still need this check for return result ? If i delete this check and will always return return res all internal VTU test passed.

@voskresla voskresla changed the title scopedSlots as Function returns only first element: res[0] scopedSlots as Function returns only first element from array: res[0] Dec 23, 2020
@afontcu
Copy link
Member

afontcu commented Dec 27, 2020

Hi!

Looks like these lines were added in a PR to close this issue a couple of years ago. Could you check if you find anything relevant in the discussion there? Otherwise I think it make sense to remove this check as long as no internal tests fail (we might be missing some, so it would be wise to check if the tests in the PR covered all cases).

Thanks!

@ebisbe ebisbe added the bug label Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants