resolveComponent() Inside Computed Property no longer works in Vue 3.4

[Pertta]

I use resolveComponent within a computed property to dynamically resolve components based on certain conditions. In my application i work with OPC UA as a data source and i have to react to change in values before i can decide exactly what component i should render and what props it should have. My current solution was functioning well in version 3.3.4 but as of version 3.4 that is no longer the case. Below is a simplified version of what i do in my application.

main.ts

import { createApp } from 'vue'
import App from './App.vue'
import HelloWorld from './components/HelloWorld.vue'
import TheWelcome from './components/TheWelcome.vue'

const app = createApp(App)

app.component('HelloWorld', HelloWorld)
app.component('TheWelcome', TheWelcome)
app.mount('#app')

App.vue

<script setup lang="ts">
import { computed, resolveComponent, h, ref } from 'vue'

const componentSwitch = ref(false)
const currentActiveField = computed(() => {
  return componentSwitch.value ? 'HelloWorld' : 'TheWelcome'
})

const field = computed(() => {
  let cmp = h(resolveComponent(currentActiveField.value), { msg: currentActiveField.value }) as any
  return cmp
})
</script>

<template>
  <component :is="field" />
  <button @click="() => (componentSwitch = !componentSwitch)" style="height: 50px; width: 100px">
    Change component
  </button>
</template>

Environment:

• Vue Version: 3.4.x
• Previous Working Version: 3.3.4

Questions

1. Has there been a change in how resolveComponent should be used with Vue 3.4.x?
2. Am i doing something that maybe never should have been allowed?

[skirtles-code]

From https://vuejs.org/api/render-function.html#resolvecomponent:

resolveComponent() must be called inside either setup() or the render function in order to resolve from the correct component context.

You can't safely use resolveComponent inside a computed, as it isn't guaranteed to be evaluated during setup or rendering.

It's essentially the same problem I described in #9974. The reactivity system was significantly rewritten in 3.4, leading to some subtle changes to the timing of when things ran. This wasn't a change to the documented API, but code that implicitly relied on the previous timing of the calls will fail with 3.4.

[Pertta]

Thanks for the answer and insight, much appreciated! @skirtles-code