getCurrentInstance type not correct

[iceprosurface]

Version

2.7.0

Steps to reproduce

vue2.7 getCurrentInstance type was not match vue3 & @vue/composition-api

export function getCurrentInstance(): { proxy: Component } | null {
  return currentInstance && { proxy: currentInstance }
}

see:

• https://github.com/vuejs/composition-api/blob/main/src/runtimeContext.ts#L184
• https://github.com/vuejs/core/blob/main/packages/runtime-core/src/component.ts#L213

What is expected?

has correct type

What is actually happening?

not match

[Akryum]

I guess you are not supposed to access the component internals :)

[iceprosurface]

In vue3:

export const getCurrentInstance: () => ComponentInternalInstance | null = () =>
  currentInstance || currentRenderingInstance

in @vue/composition-api

let currentInstance: ComponentInternalInstance | null = null
// ....
export function getCurrentInstance() {
  return currentInstance
}

They both returned ComponentInternalInstance. So vue2.7 are missing the following important function & props：

• state
  • data
  • props
  • slots
• function
  • emit
  • update

[Akryum]

They are on getCurrentInstance().proxy which is roughly equivalent to this. So you can do proxy.$props or proxy.$emit for example.

[iceprosurface]

Yes, i can do this by myself. But it cannot be smoothly upgrade from @vue/composition-api.

Is there any plan to add support for those api ?(This seems to be easy to implement)

[uyarn]

same issue :(

[yyx990803]

1. @vue/composition-api's implementation is not the source of truth - 2.7 has intentional deviations from it.

2. Only exposing proxy is intentional, because other properties on the internal instance is considered, well, internal. You should refactor any code that relies on anything other than proxy.

   This is necessary because relying on the internal instance properties when using Composition API is a sign that you are misusing it. It makes your code less reusable AND introduces risk of compatibility with future versions of Vue. We exposed getCurrentInstance mostly for official libraries that need additional internal access, not for userland application code. It was mistakenly documented in WIP v3 docs but is no longer considered a public API.

3. Vue 3 will likely start showing warnings when you rely on properties other than proxy soon.

[ulissepress]

@yyx990803 considering that this API is not public, how do you suggest to get the vue app instance (the one created with createApp() ) from any Vue component (created using <script setup>) ?

Currently I was using getCurrentInstance().appContext.app

[F0rsaken]

@yyx990803 I know it's a closed issue and I understand your point of view, and I actually agree with you, but I think it's a good think to leave getCurrentInstance in API docs, even just to mention it. Even if only advanced library authors need it, they still need to know about it.

[woahitsjc]

Does anyone know an alternative approach to get the access to the Vue instance (for v2.7)?

[jacekkarczmarczyk]

Vue instance can be accessed by Vue , same like you access it in your main.js. If you mean component instance then you can access it by getCurrentInstance() (or getCurrentInstance().proxy), not sure what would be use case for using the first one, in my apps I'm using only the second one