useId behavior in asynchronous environments

[tuskermanshu]

I'd like to start a discussion about the useId composable in Vue 3, specifically its behavior in asynchronous environments. As many of us have experienced, useId doesn't work as expected when called within asynchronous contexts such as setTimeout, setInterval, or Promise callbacks. This is due to its reliance on getCurrentInstance(), which returns null in these scenarios.

Current Behavior

Currently, when useId is called in an async context:

• It fails to generate an ID
• In development mode, it warns: "useId() is called when there is no active component instance to be associated with."

Questions for Discussion

• Was the current behavior a deliberate design decision? If so, what were the key considerations?

• How are others in the community handling ID generation in async contexts while maintaining the benefits of useId (like SSR compatibility and component scope)?

• Would it be beneficial to extend useId to work in async environments? What would be the pros and cons?

• If extending useId isn't feasible, what alternatives could we consider? Perhaps a new composable like useAsyncId?

Code Example

Here's a simple example to illustrate the issue:

<script setup>
import { ref, onMounted } from 'vue'
import { useId } from 'vue'

const message = ref('')

onMounted(() => {
  const id = useId() // This works fine
  message.value = `Initial ID: ${id}`

  setTimeout(() => {
    const asyncId = useId() // This fails
    message.value = `Async ID: ${asyncId}` // asyncId is undefined
  }, 1000)
})
</script>

<template>
  <div>{{ message }}</div>
</template>

[hubdidub]

I'm not sure, but aren't we supposed to only call use...() functions at the top-level of the setup function?
So even inside the onMounted callback, I wouldn't expect it to work. But I might be mistaken here,

[michaelcozzolino]

"use" functions are mainly composable, so they can be called anywhere in the component. useId unluckily returns a string, so that is one possible cause of this problem

[Shinigami92]

I find the implementation and relying on getCurrentInstance anyway slightly weird.

https://github.com/vuejs/core/blob/main/packages/runtime-core/src/helpers/useId.ts

Why wasn't it written like e.g. with a generator function or a global tracked state. We just want to have general unique (but simple to read) Vue ids that are targeted to be used for the html element id attribute.
At least this is my assumption.
Also it should be usable as default/fallback for property ids.

I'm not sure if it needs to be a tracked reactive, this might be a bit to overkill and to much performance loss. But to extend existing behavior with workaround, we could make it possible to pass a Vue instance and fallback to getCurrentInstance.

[LinusBorg]

Was the current behavior a deliberate design decision? If so, what were the key considerations?

Yes, this is deliberate. one of the expressed purposes of useId() was to provide stable ids between server- and clientside when using SSR (i.e. with Nuxt).

For that to work, ids can only be generated at certain points in the render cycle, specifically during component setup. Otherwise, the could not be stable between server and client and would cause hydration errors.