Feature: v-empty after v-for

[jods4]

For Vue 3 I would like to submit to your consideration a Vue 2 feature request that was rejected: vuejs/vue#4174

It's a simple way to have content when a v-for iteration is empty, which would work similarly to v-if / v-else.
The original request called it v-empty but I don't care about its name.

It's nice sugar for something that is very common in UI, but more importantly it's hard to emulate when you are iterating over something that doesn't have a length, such as an iterator/generator.

You can see that even after being closed, comments of the original issues are getting a lot of thumbs up:
Issue itself: 👍 16
vuejs/vue#4174 (comment) 👍 23
vuejs/vue#4174 (comment) 👍 13

What does the proposed API look like?

<template>
  <div v-for="x of iterator">{{ x }}</div>
  <div v-empty>Empty!</div>
<template>

Or any other name.

[mrleblanc101]

This is a critical part of most templating language.
I understand that this is syntax sugar, but it would help minimize useless nesting.
Wrapping everything with a <template v-if="arr && arr.length"> can create deep nesting.

The reason for rejection in Vue 2 is disappointing.

Do not want to add more syntax sugar.
Has workaround.

But:

1. Vue 3 is full of syntax sugar like <script setup>
2. Vue 3.2 just added v-memo which is the doc itself say you most probably shouldn't use.

So why is a high usage v-empty directive refused, but a low usage directive like v-memo implemented ?

Also, since this kind of directive pretty low level, I don't think it can be implemented as a plugin since it need to interact with the v-for directive itself which make it a good candidate for importation in core !

[matthiasg]

I do not believe it is purely syntactic sugar though. Some iterators just do not know how many elements get returned until iteration is done. Thus it is extremely easy to generate a render function with just a local boolean or counter about whether any element was rendered and render the v-empty, while it is quite annoying to first convert the iterator into an array and then use length to potentially render a v-empty eqiuvalent branch.

[jods4]

@matthiasg exactly.
As a challenge, try to create a Vue component that is a generic list:

• Takes a items props.
• Displays the items with a v-for
• Displays something different when the list is empty.
• items props should accept anything that works in v-for.

What's the easy way to create this component? The last two bullets make it tricky.

Vue could implement a more efficient v-empty and the task becomes trivial.

[louiss0]

@matthiasg exactly. As a challenge, try to create a Vue component that is a generic list:

• Takes a items props.
• Displays the items with a v-for
• Displays something different when the list is empty.
• items props should accept anything that works in v-for.

What's the easy way to create this component? The last two bullets make it tricky.

Vue could implement a more efficient v-empty and the task becomes trivial.

Can this problem be explained further I don't know how many iterators there are in Javascript and how they work. But the ones I know about all work with Object.values()

[louiss0]

I think I have an Idea on how this can be implemented. Every iterable seems to work with Object.values() . Object.values returns a .length property. An iterable's length can be determined from there. I think you should look at the Built in Iterables Page from Mozilla. All of them work with Object.values except segment.

This example demonstrates my point.

[matthiasg]

The point is that every template language has an equivalent. it shouldn't be necessary to convert iterators into arrays. and it's extremely appropriate to implement this in the render function being generated.

I think it's just a relic of an idea that it might not be strictly necessary . but semantically it would be much cleaner and there would also only be one reference on the template to the accessed list/iterator variable name.

it's puzzling why this seems to be an issue at all.

[louiss0]

Well if that is the reason why this feature is not implemented I'm not going to complain. I just wanted to help. I'm just hoping Vue will get some of the features that exist on Vue Macros. I don't see a big deal when it comes to the Array conversion but oh well.

[jods4]

Object.values does not collect all values from an iterable:

The correct method for the solution you propose is Array.from, or JS spread operator [...iterator].

This is not very satisfactory, though:

If you attempt to build a generic list component that accepts everything Vue v-for does, you'll need to do some type-checking before calling Array.from because Vue also accepts things that won't work with it, such as: plain numbers (creates a range) or objects (enumerates keys).

It also defeats the purpose of an iterator to create an array out of it. If this is the way, why does v-for even support iterators? It already supports arrays!

[matthiasg]

@jods4 I argued that same case quite some time ago when vue 2 came out, but the vue team wouldn't do it. Not exactly sure what the issue is, but its not technical.

Something like v-for-else or v-empty etc just like in every other template language absolutely makes sense.

[KazimirPodolski]

Is there any sensible way for the community to extend Vue with features like this? A Compiler plugin? A directive + Volar support?

Otherwise, it's very frustrating to see such silent gatekeeping from Vue's owners with community proposals, absolute majority of which are open for years.

[jods4]

I don't quite understand years of silence from core team considering:

• this has the most the thumbs up of all features on vuejs/rfcs (at the time of writing 74, second is @click.outside modifier with 71).
• it is easy and lightweight to do in core (I think?)
• it is tricky to do completely and efficiently in user-land (beyond the array.length case).

in the same vein, <suspense> was a flagship new experimental feature when Vue 3 released in September 2020... 5.5 years later it is still experimental... I understand they needed time and feedback for the feature to mature but that seems much.

[KazimirPodolski]

I can only guess it's just core team's interests drifted to other things, voidzero and whatnot. Vue's core barely had any attention last years (and half of it is renovate), especially comparing to Angular or React. Ofc we cannot blame people for trying to make profit off their work, but current state of neglect is sad nonetheless.

I guess it'll all come down to the classic "feel free to fork".

[jods4]

That's a bit harsh... they have put a lot of energy into Vapor mode, better devtools, faster reactivity and other improvements.
The new Rust-based tooling (Vite/Rolldown/Oxc) is free and benefits Vue developers directly.

I don't think it's "make profit" as much as "make a living". Vue is free and donations to OSS developers are few.

[KazimirPodolski]

Well I guess you're right. But not about this:

I don't think it's "make profit" as much as "make a living". Vue is free and donations to OSS developers are few.

As far as OSS goes, Vue is spectacularly well funded. Just looking at Open Collective + assuming GitHub donations are on par with the old Patreon = a number of fulltime devs (and not even "making a living" but first-world-salaries devs). Plus other sources they have. The issue I see here is those devs are nowhere to be seen in Core 😞.

I can only hope they'll find a way to milk the corporate with VoidZero or something, and get an actual revenue stream. We should see some good spilling on us too.

[louiss0]

Is there any sensible way for the community to extend Vue with features like this? A Compiler plugin? A directive + Volar support?

Otherwise, it's very frustrating to see such silent gatekeeping from Vue's owners with community proposals, absolute majority of which are open for years.

I know. But you can use vite.

[KazimirPodolski]

Cool but please expand. How do we use Vite to extend Vue in a way similar to adding something to the core?