No warning for multiple refs with same name

[dsandber]

What problem does this feature solve?

Both I and a colleague have spent hours debugging issues caused by having two refs with the same name. Two cases where this can happen:

1. Simple stupidity:

<comp1 ref='comp'/>
<comp2 ref='comp/>

2. Not realizing that refs don't seem to work in a v-for:

<tabs v-for='title of titles'>
<fubar v-if='title==="FUBAR"' ref='fubar'/>
</tabs>

In this case, it is reasonable to assume the ref would work correctly because there will only be one "fubar" component instantiated assuming 'titles' has no duplicates. But the ref does not work right, either because ref ignores "v-if" or because ref doesn't work right in v-for.

What does the proposed API look like?

Simply issue a Vue warning when multiple refs with the same name are encountered.

[LinusBorg]

The second one sounds rather like

a) a mistake on your part or
b) a bug

Could you provide a small reproduction of the problem as it appears to you?

---

Sidenote: Are you aware that refs in a v-for end up in an array?

[LinusBorg]

@nickmessing

• About 1.: I think this should be solved in eslint-plugin-vue, instead of adding yet another warning into the core lib.
• About 2: Would be a bug if true.

So I would remove the improvement label and ask the OP to suggest this as a rule in the repo of eslint-plugin-vue. OK with you?

[nickmessing]

@LinusBorg, agree 👍

[dsandber]

Disagree -- the problem is that the refs might be specified programatically, in which case no warning would be issued even though they would save the user a lot of trouble. Some possibilities:

<component :ref='calc_ref'/>  [is colon in front of ref allowed?]

<component v-if='condition1' ref='fubar'/>
<component v-if='!condition1' ref='fubar'/>

In 2) a linter would warn even though it shouldn't -- the two cases are mutually exclusive. A linter doesn't have enough information to reliably determine duplicate references -- only at run-time is there enough information.

[dsandber]

Incidentally I will try to come up with a simple test case for my original second example in the next week.

[LinusBorg]

I can concede that a linter will not catch dynamic $refs in many cases. For that, we would have to implement a warning mechanism.

However, a simple check does this ref already exist isn't enough either, because it's totally valid to overwrite $refs. We would somehow register all $ref assignments during the run of a render function and check for any ne assignment if it has been assigned privously in the same render run.

Will have to think about how that's feasable.

[nickmessing]

@LinusBorg, there is one easy way, Proxy, we just need to wait for the drop of IE support 😅

[yyx990803]

Closing due to inactivity. Please open a new issue with a reference to this one if you can follow up with more information.

[neel]

I also stumbled on (1). I need that, It is not an unreasonable feature.

If there can be multiple elements with the same ref then it should be possible with or without v-for. Otherwise definition of ref is unstable.