[feature request] new `v-slot` syntax does not support slot names that start with a square bracket `[` or names with spaces

[tmorehouse]

What problem does this feature solve?

We use slot names that use a bracketed syntax (specifically for dynamic slot names) i.e. slot="[foo][bar]").

v-slot: currently supports slots names with square brackets, as long as they are not the first character of the slot name. i.e. v-slot:foo[bar]="scope" (works), but not v-slot:[foo][bar]="scope" (does not work)

HTML5 allows for custom attributes with square brackets in the attribute name, as long as they do not start with restricted characters. However, in the case of v-slot, the attribute starts with v, so slot names that start with [ should work as expected (i.e. v-slot:[foo.bar] or v-slot:[foo][bar])

Using the deprecated slot="[foo]" syntax works as expected.

What does the proposed API look like?

v-slot adds support for slot names that start with a [, such as v-slot:[foo][bar]="scope"

There is no actual change to the API from the user perspective, just a change to the underlying code.

My guess that this is an issue with Vue template compiler:

From the template compiler on the Vuejs.org site (https://vuejs.org/v2/guide/render-function.html#Template-Compilation):

Does not work:

Does Work:

[posva]

Unfortunately, brackets are for dynamic slot names: https://vuejs.org/v2/guide/components-slots.html#Dynamic-Slot-Names

so you will have to use a different naming convention

[jacekkarczmarczyk]

[tmorehouse]

@posva will using a name such as v-slot:foo[bar]="scope" and v-slot:foo[bar][baz]="scope" be safe for future use? As the square brackets makes sense when referring to slots based on a multi-dimensional array of data (our component is dynamic when it comes to slot name, so the slot names will change based on user supplied data)

[sirlancelot]

I would've expected a bracketed string literal to work, but it appears the parser doesn't like that:

<component>
  <template v-slot:['[foo][bar]']>TEST</template>
</component>

Template Explorer Example

[jacekkarczmarczyk]

@sirlancelot it works with backticks though (see my example), maybe it should be documented?

[posva]

quotes seems to be forbidden. Since they can be used to delimiter value in html attributes (data-attr="hey" or data-attr='hey') but that's not the case for the backticks. Or that's what I think the intention was and if that's the case, it should be documented at https://vuejs.org/v2/guide/components-slots.html#Dynamic-Slot-Names. But I don't know if we the recommendation would be to also avoid strings like [foo][bar]. Although that could also be changed in the regex
Keep in mind there is a PR at #9785 and that would be the regex that needs to be modified to accommodate new cases

Personally I wouldn't use a name for a slot if it cannot be used as a variable name. It also makes it easier to access them through $scopedSlots. I would use a delimiter to split the namespaces so they can be easily joinable. Something like $ or _: foo$bar. That way can be easily walkable with functions in nested objects. But at the same time, if a key doesn't create any problems to be parsed in html and can be used as the key of an object, it would make sense to support it

[tmorehouse]

@posva For reference, here is our use case of the slot names which are determined at runtime:

https://bootstrap-vue.netlify.com/docs/components/table#custom-data-rendering

Note that we are using render functions internally to generate the table cells. Users provide a list of "fields" for their table, and we look to see if the user has provided a slot for that field to do custom rendering on the cell.

Note that each field name could contain dot (in the case the field's key points to a nested object value in the table row), underscores, letters, numbers (and in some cases spaces... anything that can be used as an object property key)

[Justineo]

You should use scoped slots.

[tmorehouse]

@Justineo we are using scoped slots (we are providing the scoped slots to consumers, and the consumers use these slots to place their custom formatting in).

The issue is that the slot names are defined by the consumer, following a particular naming convention. As the library provider, we do not know the full name of the scoped slot until runtime (when the user provides a list of fields for the table data). We then lookup in the $scopedSlots object to see if a scoped slot exists for a particular field, and if it does then we use that, other wise we just render the table's row's field data as is.

[Justineo]

I see. But what would v-slot:[foo][bar] mean in your example?

[tmorehouse]

It was just an example for using brackets in slot names. We were also thinking of, in the future, a way to target specific rows/columns (cells) based on the [x][y] axis. The older slot="name" syntax had a lot more flexibility when it comes to slot names, compared to v-slot:name syntax which is restrictive due to limitations of what is allowed in attribute names (as well as the loss of case sensitivity in slot names, specifically if a consumer is using in-document templates)