Why `getCurrentInstance` is descriped as anti pattern in application code?

[Donskelle]

I really dont understand why getCurrentInstance is descripted as anti pattern in application code.

Here is the documentation part that i mean: https://github.com/vuejs/docs/blob/10ed910a8c7f6cad665aa74e7c0e921107b34868/src/api/composition-api.md?plain=1#L216-L223

I am working on a large vue 2.6 codebase and in my optinion using getCurrentInstance can be a great improvement for reusable hooks, which need SetupContext. Currently we are passing the context, but in my option it makes refactoring hard and i think it would be a great improvment to use getCurrentInstance in some cases.

Whats the reason its descripted as anti pattern?

• SetupContext Type doens't get extended?
• Is it a perfomance problem?

For example a nested hook needs some vuetify variable of SetupContext or use of a Router without Provide / Inject API

[yyx990803]

Because the instance is an internal instance that exposes non-public APIs. Anything you use from that instance can technically break between any release types, since they are not subject to semver constraints.

I'm not sure why you need the setup context in nested composables, but explicitly passing arguments to composables make them less coupled to the consuming component, thus easier to understand and test in isolation.

In general a library designed to work with Composition API should expose special variables via its own composables (e.g. useRoute from vue-router) instead of the requiring the user to grab it from the instance.

[Donskelle]

Ahh thanks for your response and clarification.

Yeah the nested composables doesn't make much sense. We are trying to keep component setup code as short as possible. So we have a lot of code like this:

// setup example
return useCustomerTable(props, context);

This is where a lot of nested composables come from

[paridigm]

Re:

 :::warning 
 `getCurrentInstance` is only exposed for advanced use cases, typically in libraries. Usage of `getCurrentInstance` is strongly discouraged in application code. Do **NOT** use it as an escape hatch to get the equivalent of `this` in Composition API. 
 ::: 

Quote:

Do NOT use it (getCurrentInstance) as an escape hatch to get the equivalent of this in Composition API.

As a long-time Vue2+Vuex developer recently switching to Vue3+Pinia for a new project, the <script setup> API initially felt weird to me. But, after using it a bit, it feels like a fresh new framework that provides easier scalability and less boilerplate to where I even want to exclusively use <script setup> in my components to keep my codebase uniform/clean. And, I'm sure I'm not the only developer who has adopted this convention.

Assuming you can do everything that you are able to do with the options API (plus more), it seems like a good decision. However, when interfacing with VanillaJS libraries, I often use this.$el.

But, if getCurrentInstance isn't the standard way to access this.$el anymore, then what is?

I found a post on Stack Overflow that said you can put a template ref on the root element of your component. Is that the new convention for accessing what used to be this.$el?

Thanks in advanced!

UPDATE After looking more into it, I take back the idea of using exclusively <script setup>. There are some corner cases that aren't possible with it. Src: https://vuejs.org/api/sfc-script-setup.html#usage-alongside-normal-script

[amidnikmal]

I really dont understand why getCurrentInstance is descripted as anti pattern in application code.

Here is the documentation part that i mean:

https://github.com/vuejs/docs/blob/10ed910a8c7f6cad665aa74e7c0e921107b34868/src/api/composition-api.md?plain=1#L216-L223

I am working on a large vue 2.6 codebase and in my optinion using getCurrentInstance can be a great improvement for reusable hooks, which need SetupContext. Currently we are passing the context, but in my option it makes refactoring hard and i think it would be a great improvment to use getCurrentInstance in some cases.

Whats the reason its descripted as anti pattern?

• SetupContext Type doens't get extended?
• Is it a perfomance problem?

For example a nested hook needs some vuetify variable of SetupContext or use of a Router without Provide / Inject API

that is very strange advice from documentation..

What if i want gradually migrate from options api to composition api. And what if i have only vue 2.7 and bunch of legacy code and old libraries, that don't have composition api possibilities - but that libraries required to bypass rewriting all legacy code that rely on them. All what i can do is using getCurrentContext as a glue between composition api to options api to access some this.

If getCurrentInstance is not recommended , than might be introduced good way to access component instance (like in options api) to composition api for the sake of gradual refactoring a lot of legacy code