Skip to content
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

v-slot directive: Varying behavior depending on how the slot is named. #9607

Closed
cicsolutions opened this issue Mar 2, 2019 · 1 comment
Closed

Comments

@cicsolutions
Copy link

cicsolutions commented Mar 2, 2019

Version 2.6.7 on my computer, not sure about the version used in jsfiddle

Reproduction link

https://jsfiddle.net/cicsolutions/qkzjp520/6/

Steps to reproduce

Create three named slots: (1) with no dash in the slot name, like 'header' or 'footer', as in the docs. (2) with a dash in the name, like 'card-header' and (3) with a camelCased slot name.

Console log the slot contents at the created and mounted hooks (other lifecycle hooks not tested) of the component.

What is expected?

I would expect the slot contents for all slot name syntaxes to be available at in the lifecycle hooks and rendered in component. (unsure if hyphenated or camelCasing is preferred for compound names)

I would 100% expect that if the contents of the slot can be logged to the console during created/mounted hooks, that it could be rendered via the render function (which appears to not be true for camelCased slot names)

What is actually happening?

The slot content for a slot where the name contains a dash is undefined at the created hook, whereas the slot content where the name does not have a dash is defined as expected with the slot node object.

Most strange ... content for the slot with a camelCased name is logged to the console properly, but not rendered in the component.


Please let me know if this type of report is unhelpful. I really don't have the time to first search the forums and such, and I'm still learning Vue, so I'm unsure if for some reason this would be intended behavior.

I do not see anything in the docs that gives notes about the syntax for the slot names that may be compound phrases/names. However I thought I read somewhere in the docs that camelCase is not valid HTML, so i first figured the hyphenated version of the slot name would be correct.

It does make sense to me that the value that follows the colon in the directive declaration becomes the $slots object key, and the value is not rendered as a DOM element attribute, so I thought perhaps using camelCase is the proper way to have compound slot names. But when using camelCase slot names, the slot content does appear in the console, but is not rendered via the render function. So ... that's even stranger!?

It would be great if the docs could touch on the proper naming convention for slot names, as compound slot names seem like they would be a pretty common approach to slot naming.

Note: I did not test other lifecycle hooks.

Perhaps I'm not understanding slots properly, but it seems strange to me that a slot named with a dash will render properly but show as undefined for in the created/mounted hooks. And the opposite: having a camelCase slot name does show a correct node value in the hooks, however does not actually render the slotted content.

Hope this helps! Thanks so much for all you do! Vue is simply the best framework I've ever used!

@cicsolutions cicsolutions changed the title Slot Directive Undefined at Created & Mounted Hooks When Slot Name is Hyphenated v-slot directive: Varrying behavior depending on how the slot is named. Mar 2, 2019
@cicsolutions cicsolutions changed the title v-slot directive: Varrying behavior depending on how the slot is named. v-slot directive: Varying behavior depending on how the slot is named. Mar 2, 2019
@posva
Copy link
Member

posva commented Mar 3, 2019

Duplicate of #9449

@posva posva marked this as a duplicate of #9449 Mar 3, 2019
@posva posva closed this as completed Mar 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants