Vue: Handle "for" attribute with server-rendering

[harvey-woo]

Vue.js version

2.1.4

Reproduction Link

``` html:

```

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?

[TiBianMod]

try one time

export default {
    data() {
        return {
            id: `id-${this._uid}`
        }
    },
}

[defcc]

@Alphmega will you please try the latest Vue.js version, it might be fixed already. Works on my Mac chrome.

[harvey-woo]

@defcc Excuse me, I wrote the wrong description of this issus. I am using 2.1.4

[harvey-woo]

@defcc I upgraded vue 2.1.7 and still have the same problem

[harvey-woo]

@TiBianMod This solution works.

[yyx990803]

Hydration skips patching the attrs because the server-side rendered markup is assumed to be the same with what the client renders. Date.now() is impure (i.e. it's not included in the initial state used for the client-side render) and causes your server markup to be always different from the client, and you should just avoid using that during renders.

[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.

[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.

[thedamon]

One fairly simple way of solving this without a whole lot of mucking around (on the user end at least) would be to have an option that DOES check id attributes for patching. Not sure what impact that would have on the underlying code, though.

It will likely only be an issue if the client and server behaviour are different — for us it's that the server already has all our modules loaded, whereas on the client we load components asynchronously because not all pages need all of them, so the modules arrive and register themselves in a different order.