What problem does this feature solve?

We use instance.vnode.key to process the component logic. Due to historical reasons, changing the api design is a costly thing. vue compiler-sfc will automatically generate a 0 or 1 key for the v-if v-else component. We cannot judge how this key is generated. Is it possible to change the keys of v-if and v-else to other fields or use special values?

What does the proposed API look like?

use { internalKey: xxx } or { key: 'some special value' }

We use instance.vnode.key to process the component logic. Due to historical reasons, changing the api design is a costly thing.

Rather than saying "We just don't want to update our codebase", what is the actual case for reliying on vnode.key ?

vnode.key does not have to be dependent. We can use other attributes instead. But because the historical component has already used the key to process the component logic. Our usage scenario is that the child component passes the key to the parent component through the inject method. The parent component will use the key to make some judgments. like https://github.com/vueComponent/ant-design-vue/blob/next/components/menu/src/SubMenu.tsx#L49 Menu component use openKeys selectedKeys to control menu state.

I think relying on Vue's internal implementation isn't a very good idea. For your use case, it seems that you can just treat numbers as Vue-generated keys as your API says user-provided keys should be strings. But again, it's not safe as Vue may alternate the type of auto-generated keys in the future.

v-if and v-else , etc uses auto increment key, which is set on the node.key as well on the node.props.key making it impossible for you to know if the key was set via a prop or via the magical implicit v-if v-else conditional rendering .

your mistake was that you use key attribute/prop which is not just special but also a technically reserved attribute by vue for its voodue logic .

your options is to use the the type assetion, but in your case, there is no guarantee that your component users didn't set a none string key. and relying on that is worst then relying on key for your derived functionality.

your only viable option, is to refactor your logic to not use key, (use a different name) or if possible add check that the node with the key is of the tag/component type you intended to key.

Thank you for your suggestions.

I know this is an unreasonable way to use it, but due to the high cost of component changes to the API, it will be a breaking change.

Is it possible for Vue to expose the key to users and use other name or use special values as Vue-generated keys.

I am correct to assume that this request is now outdated? @tangjinzhou

Or are you still waiting on this for your migration?