Expose _uid as public value in Vue instances

[benjarwar]

What problem does this feature solve?

I'm adding aria roles for accessibility to a Vue component. This requires setting a unique id attribute on an HTML element in my component's template. I don't have any additional requirements for the id, aside from it being unique on the page.

Rather than manage these instance attributes from a higher level, I'd like the component itself to create an id and render the appropriate aria-controls and id attributes. A good example is a collapsible/accordion-style UI, the template of which could look like this:

<template>
  <div class="collapsible">
    <button @click.prevent="toggle" :aria-controls="uid">
      <slot name="toggle"></slot>
    </button>
    <div :id="uid" v-show="expanded">
      <slot name="content"></slot>
    </div>
  </div>
</template>

What does the proposed API look like?

Using the template above, I'd have a method that sets the uid value. I don't like proposed solutions that reference this._uid, since that's a private value and subject to change in the future.

Instead, I'd like to set the uid value based upon a publicly available identifier at vm.$uid, something like this:

export default {
  data: () => {
    return {
      uid: ''
    }
  },
  created () {
    this.uid = `my-component-label-${this.$uid}`;
  }
}

That way, if I have multiple instances of the same component on the page, they get unique id attributes without needing to first declare those values from the parent application, or resorting to more complex means of generating random strings.

[kaorun343]

@benjarwar

Hi. How about doing like this below?
Then, there's no need to expose it as public.

<template>
  <div class="collapsible">
    <button @click.prevent="toggle" :aria-controls="uid">
      <slot name="toggle"></slot>
    </button>
    <div :id="uid" v-show="expanded">
      <slot name="content"></slot>
    </div>
  </div>
</template>
<script>
let uid = 0

export default {
  data () {
    uid += 1
    return {
      uid: `my-component-label-${uid}`
    }
  }
}
</script>

[yyx990803]

The vm _uid is reserved for internal use and it's important to keep it private (and not rely on it in user code) so that we keep the flexibility to change its behavior for potential future use cases.

For userland use cases, I'd suggest generating UIDs yourself - you can write a simple module/service that generates uids and import it into your components, or, if you want it for every component, make it a (global) mixin.

[nirazul]

@benjarwar I needed a uid for the exact same reason. Creating your own uid is fairly simple. I'd recommend using a mixin that sets a variable on the component but not in the data object, as this will make the uid observable, which is not necessary at all.

You can set one within the beforeCreate hook as this is the closest lifecycle hook to where the internal _uid property is set:

let uuid = 0;

export default {
    beforeCreate() {
        this.uuid = uuid.toString();
        uuid += 1;
    },
};

[benjarwar]

Thanks for the replies, @kaorun343, @yyx990803, @nirazul! One of the aforementioned will work. Still kinda wishing there was a public ID for each component out-of-the-box, but I understand the need to keep that value private.

[thedamon]

I also agree a built-in or officially endorsed way of uniquely identifying a component would be nice, expecially since it's so useful for making things properly accessible. I was using the uniqid library, but it was returning the same ID for a number of components.. not particularly unique :|. I'll go forward with the mixin method outlined above.

[yinsang]

If your uid is not used by other compoment, I have an idea.

uid: Math.random()

Simple and enough.

[koresar]

I tested the uid: Math.random() solution a few times. I have never yet seen two identical numbers. It just never happens.

The following code generates random numbers and waits for two identical. All tests abort with OutOfMemory exception.

>  var s = new Set(), n; while(1){ n=Math.random(); if(s.has(n)) {console.log(s.size); break;} else s.add(n); if(s.size%1000000===0) console.log(s.size); };
1000000
2000000
3000000
4000000
5000000
6000000
7000000
8000000
9000000
10000000
11000000
12000000
13000000
14000000
15000000
16000000

<--- Last few GCs --->

[28174:0x102801000]    73065 ms: Scavenge 551.6 (584.3) -> 551.6 (593.8) MB, 38.6 / 0.0 ms  allocation failure

I admit that Math.random() is a simple and robust enough solution.

[tryforceful]

This seems to be a good solution for the underlying issue of having non-unique IDs in your DOM across multiple components.

https://www.npmjs.com/package/vue-uniq-ids

[thedamon]

Editing this comment as _uid does indeed fail now that we are doing hydration. The server rendered id and the clientside id are different, and not always updated within components the same way.

The same issue occurs with Math.random()... while the Vue devtools list the same values, the actual markup on the page is out of sync (it looked like the default prop function was being called twice based on logging, but switching to an iterator worked).

I'm just using a mixin that uses the _uid property currently since it works perfectly right now despite the warning.

This is working for now, but I'm a little worried it will have an issue with hydration the way Math.random did:

let count = 0
export default {  props: { 
 id: {
  type: String,
  default: function() {
    return this.$options.name + '-' + count++;
} } } };

Still think Vue.js would do well to make this more out-of-the-box given that without it many devs won't bother making things properly accessible and the whole web suffers as a result.