Handle "for" attribute with server-rendering

Vue.js version

2.1.4

Reproduction Link

<template>
  <div class="radio">
    <input :id="id" type="radio" name="name">
    <label :for="id"><slot></slot></label>
  </div>
</template>
<script>
export default {
  data () {
    return {
      id: `ip-${Date.now()}`
    }
  },
};
</script>

Steps to reproduce

1. Run rendering in server and generate “id” with timestamp.
2. Run vue in browser, “id” was being overridden by vue, but “for” attribute was not overridden.

What is Expected?

How can i get same value of both “id” and “for” attribute

What is actually happening?

[thedamon]

This is an interesting situation.

for id aria-describedby, aria-labelledby, controls etc are attributes that absolutely must be controlled properly in order not to break accessibility.

In order to make vue components accessible out of the box we do things like generating “unique” IDs to pass around within the component and potentially its children. If these attributes are not matching between the server and the client, the site may break for a screenreader, despite potentially going unnoticed because it is not a visual issue.

This is why I think #5886 is important. A best practice for referencing elements in order to create reliable ID references clientside, serverside, and hydrated is important.

We tried a needsId mixin that referenced to _uid, then Math.random and then referencing a self incrementing integer. The former 2 DO NOT WORK once hydrated. The latter seems to, but it’s also not totally clear when or how to make sure it does. We have it generated by a prop default function… other people might put it in computed, or data… and I’m not quite sure when patching would or would not occur with those situations, and not really sure why the incrementing ID seems to be working when Math.random() isn’t (if it’s getting a new number it’s getting a new number).

But I am sure that reliable reference to attributes for accessibility reasons is really important and really worried about SSR if it silently makes your site inaccessible. It now seems quite possible that any interactive Vue component in the ecosystem that has attempted to be accessible out of the box might silently fail to be accessible in SSR and not be likely to have tests specifically targeting hydrated markup.

[cjblomqvist]

Is there a proposed workaround for this issue?

In https://github.com/vuejs/vue/issues/5886#issuecomment-308625735 @yyx990803 state that it’s recommended to generate your own uid and not go with @TiBianMod 's solution, but clearly it doesn’t work with SSR in a practical manner?

I also do believe this only causes issues in dev environments (possibly only with HMR). In production, I guess the id-attribute is also skipped? This is probably why not many people have complained.

My scenario is I’d like to have a working dev environment using SSR and HMR to be as similar as possible to a prod environment, but still with the “dev environment” benefits (such as HMR, etc).

PS. this._uid doesn’t seem to work reliably either, probably for the same reason.