<whatever-compo /> VS <component /> performance ?

[Namidas]

Probably this has been asked before (couldn't find anything though), what about the performance of <component> VS the component itself ?
I just read the documentation and it's pretty clear (I would say):

component-like features and part of the template syntax. They are not true components and are compiled away during template compilation

Does this mean that if I make the biggest most robust app ever, and every single component (on template) is

<component :is="'my-compo'" />

instead of...

<my-compo />

...it'll all be the same performance-wise? (except, of course for loosing let's say a processor microtic while compiling the template because it checks the "is" prop instead of taking the compo name from tag name)

And what if instead of passing a string to the "is" prop I were to use a reactive ?

Essentially, I'm trying to provide a theme-like approach where you can "extend" (change) just any "core" compo (not just styles), I've already done this (don't know how to test performance though) but with just 2 or 3 "main" compos, and was wondering how far down that rabbit hole can I go before everything comes crashing down.

Based on what the docs say, there should be no difference in doing just anything only using <component> ...but, you never know, maybe vüe3 devs can shed some light on this ?

Thanks in advance =3

[Shyam-Chen]

<FooComp />

<component :is="hasSth ? FooComp : BarComp" />

[Namidas]

<FooComp />

<component :is="hasSth ? FooComp : BarComp" />

Sounds like you're explaining how to use <component /> but I'm asking about inner workings and performance on a context of using it N amount of times, where N is tangent to infinite (so to speak).

[leopiccionia]

The answer is no.

<component is="MyComp"/>

Is compiled into something like:

h(resolveDynamicComponent('MyComp'))

While

<my-comp/>

Is compiled into something like:

h(MyComp)

If MyComp is not in scope, then Vue compiler adds a hoisted call like this:

const MyComp = resolveComponent('MyComp')

I'm not sure if Vue optimizes <component :is> like this (probably not), so there may be some performance penalty.

---

But I think that what the documentation is trying to express is that, during runtime, the <component> HTML element (or an instance of a hypothetical component called Component) does not exist, it's just syntax, just like <template v-for> ou <template v-if> does not mean the presence of a <template> element in the HTML output, so there's no extra memory usage, etc.

[Namidas]

Very nice, specially the first part, didn't think of it that way, I mean the part where it would (or not) use resolveDynamicComponent (which absolutely makes sense when keeping scope in mind).

Still gives me the sensation that even though it may have a performance penalty it probably is just that: resolving the compo, if that is in any way cached (the resolving part I mean, not whatever else) then it shouldn't be much of a problem I think (or even so, if it would only resolve it on re-render and that may potentially be a fast operation, the resolving part, it may not be that much of a penalty either).

I'm not going to use it a infinite amount of times though XD
Just trying to understand how far can you go with that idea before it becomes a serious problem.

On the other hand, what's the diff between resolveComponent and resolveDynamicComponent ?
Couldn't find anything googling for resolveDynamicComponent except for russian documentation that is (curiously enough) in english (here) and that seems to be copypasta from what can be found here (for resolveComponent).

Thanks in advance ♥

[leopiccionia]

Take this with a pinch of salt, but, from what I understand:

• resolveComponent is for when the compiler is sure it's receiving a string e.g. <my-comp>
• resolveDynamicComponent handles cases where the compiler is not sure what it's dealing with e.g. <component :is="MyComp">; the variable MyComp may hold a string, another valid value (e.g. a component object or a render function) or even a completely invalid value (e.g. a number or a symbol)

[Namidas]

In other words, back to scope ?
So, when "locally resolvable" then resolveComponent, otherwise resolveDynamicComponent ?

[leopiccionia]

Not exactly.

If receiving a string, resolveDynamicComponent behaves very similarly to resolveComponent. But resolveDynamicComponent also handles the other cases that <component :is> can accept (functions, objects, etc.).

About scoping: at least in some cases, like SFC with <script setup>, Vue can skip resolveComponent entirely if the component is already in scope.

So, in <script setup>, something like

<script setup>
    import MyComp from `./MyComp.vue`
</script>

<template>
    <MyComp/>
</template>

Is optimally compiled into something like

h($setup['MyComp'])

where $setup is a variable accessible inside the render function (no need for resolveComponent('MyComp')).

---

You can explore more cases in https://play.vuejs.org/.

[Namidas]

Nice, thanks.

But, going back to my original question...

...it'll all be the same performance-wise? (except, of course for loosing let's say a processor microtic while compiling the template because it checks the "is" prop instead of taking the compo name from tag name)

Do these dynamic components get re-resolved all the time or it works more like a computed? Like: ok, you DO have some performance penalty on first resolve, but as long as the compo name doesn't change (so to speak) you don't get that again.

In other words, does that result from the compo resolution gets saved/cached/whatever in any way ?

If there was a componentResolved trigger or something like that, I could check it myself with a simple console.log, but I believe there's nothing like that.