Auto-Generated IDs + SSR (Hydration Mismatch issue)

[nikuscs]

It seems like the latest Vue version also warns about attributes miss matches on SSR, this causes a lot of warnings on Radix Vue since the ids and auto-generated IDs are different on Server and Client ( actual miss match ), while some of them you could "force" by passing the attributes down, others are not that easy. ( And there is also no good way as far as i know to turn the warnings off )

Im wondering if it could be a nice solution to allow the users to:

• Control how IDs are generated ( so for example in Nuxt we could use something that work for both Server & Client )
• Have Radix Vue to have his own useId function that is SSR Ready ( Similar to React useId() )

Ideas / Discussions:

• https://github.com/danielroe/vue-bind-once
• Can vue provide `useId` hook vuejs/rfcs#557
• https://github.com/liip/chusho/blob/main/packages/chusho/lib/composables/useCachedUid.ts#L20-L41
• https://github.com/shimyshack/uid

[zernonia]

Thanks @nikuscs . Could you share a minimal repro of this warning happening in SSR context?
Internally we have useId(), but this might be causing different value generated in Server/Client context.

[nikuscs]

There is no need a reproduction i believe, simply install the latest Vue beta , and import for example an accordion component, you will see stuff like : aria-controls="radix-26" will be 26 on the server but 81 lets say on the client. The actual DOM inside will be the same but recent Vue update also warns about the attributes diff. The useId() works ok but its not aware of the Server, so it will always warn about miss match. I trully believe Vue itself should be the one providing this hook but meanwhile i think we could probably use something like the Daniel Roe Package.

[sadeghbarati]

Agreed 👍

Idk why Vue team don't provide this composable/hook
They simply can refer to React source and see what is missing in Vue

[nikuscs]

Just a quick update here that the latest Nuxt version also bumps Vue, @zernonia do you wanna discuss this approach to implement anytime soon? it really bloats the browser console as it is.

[zernonia]

Yeah I believe we should look into this!

[nikuscs]

After investigating and playing around a bit it seems no trivial issue to solve, probably lack of my deep understanding of the vue core, but i cant figure out how do we pass data from SSR generated into the actual client. Daniel package probably wont work since its bound with a directive, so we cannot "use" it outside of it, we can just bind it directly but not extract it, i have played around even with a Vite Plugin to see if we could get something fancy but couldnt get my way around it :\ I guess we have to push more forces into the Vue side to get this out of the door probably in Vue Core.

Also Relevant: nuxt/nuxt#13406 and https://github.com/nuxt/nuxt/pull/23368/files#diff-56fa79b2b6b6d55801e7e885441f1ee98891adfbbe7d11844721dcfdc2dc5583

But Radix still needs to adapt, example : https://github.com/radix-vue/radix-vue/blob/b8eb9e37ea198e88f87535e5aa6f6a938f90aa2e/packages/radix-vue/src/Tabs/TabsRoot.vue#L72C11-L72C16

This is using a hard-coded useId() so even if we can generate unique Ids externally we cant hook into that provide :p

[nikuscs]

If you are using Nuxt, you can grab the code from that PR into a composable :

import type { ComponentInternalInstance } from 'vue'
import { getCurrentInstance } from 'vue'
import type { NuxtApp, NuxtPayload } from '#app'

const ATTR_KEY = 'data-n-ids'

interface ComponentInternalInstanceExtended extends ComponentInternalInstance {
	_nuxtIdIndex?: number
}

interface NuxtAppExtended extends NuxtApp {
	payload: NuxtPayload & {
		_id?: number
	}
}

/**
 * Generate a ssr-friendly unique Id that can be passed to accessibility attributes.
 */
export function useId(key: string = 'uid'): string {
	const nuxt = useNuxtApp() as NuxtAppExtended
	const instance = getCurrentInstance() as ComponentInternalInstanceExtended
	if (!instance) {
		throw new Error('[nuxt] useId() must be called within a component.')
	}

	if (nuxt.payload._id === undefined) {
		nuxt.payload._id = 0
	}

	let id

	if (nuxt.payload.serverRendered && nuxt.isHydrating) {
		instance._nuxtIdIndex = instance._nuxtIdIndex || 0
		const serverIds = instance.vnode.el?.getAttribute?.(ATTR_KEY)?.split?.(',') || []
		if (serverIds.length) {
			id = parseInt(serverIds[instance._nuxtIdIndex], 10) || 0
			instance._nuxtIdIndex++
		} else {
			if (!instance.vnode.el?.getAttribute && (!instance.parent || instance.parent.type.name !== 'ClientOnly')) {
				console.error('[nuxt] useId() needs to be used with a component having on single root element.')
			}
			id = ++nuxt.payload._id
		}
	} else {
		id = ++nuxt.payload._id
		if (import.meta.server) {
			if (instance.attrs[ATTR_KEY]) {
				instance.attrs[ATTR_KEY] = `${instance.attrs[ATTR_KEY]},${id}`
			} else {
				instance.attrs[ATTR_KEY] = id
			}
		}
	}

	return `${key}_${id}`
}

[zernonia]

Thanks for the research @nikuscs . The directive by Daniel might not be the best way, as it assign id when the element is mounted, and we need extra work/refactor just to make it assign into the provide context.

The idea of why we use useId in Root is because we only generate it once, and the child element would use the generated id as their 'id'. So if the child element was remounted (unmount -> mount), the id stays the same.

[nikuscs]

Yeah, that was my point, this code above is not from the directive, but from nuxt itself, that should be merged soon ( hopefully ), and i can see it working very good with the edge cases that you mentioned, you can useId() on the root and let it flow to the rest of the child components naturally, if the root ever re-mounts for whatever reasons, a new ID is generated indeed in this case, but thats only the client side already, so there is no SSR issue in this case, the only con with this approach is that it would make it "nuxt-only" solution, being Radix-Vue framework agnostic is not a good solution, in any case im pretty sure a good start would be letting the user provide a way to generate Ids, so people who use nuxt can override the way IDs are generated, while in the future we could probably check how can we get this into a proper Vue Solution.

[Atinux]

Indeed, I re-wrote the useId composable in nuxt/nuxt#23368

I still need to make some improvements before it to be ready.

Though, I still believe having a solution from Vue itself is the best scenario.

[remonke]

tailwindlabs/headlessui#2959

How about Radix implements something similar as a temporary fix?

[roybarber]

Can we not switch to: https://nuxt.com/docs/api/composables/use-id

[zernonia]

Nope. The useId created by Nuxt is only Nuxt compatible. The fix should be coming from vue itself, where it should have a ssr-friendly solution.

[roybarber]

Good point, im using in nuxt so was looking for a personal solution. Completely disregarded the ability to use anywhere!

[SwartZCoding]

Have same issue. What can i do to fix this ?

[remonke]

HeadlessUI provides the ability to override the default useId composable with the one provided by Nuxt

tailwindlabs/headlessui#2959

You can check this out

[SwartZCoding]

HeadlessUI provides the ability to override the default useId composable with the one provided by Nuxt

tailwindlabs/headlessui#2959

You can check this out
Does it work for radix components ?

[remonke]

No, but HeadlessUI is very similar, so you can use it instead

[zernonia]

Fixed with #577 (comment) 😁