SFC compiler: hoist constant literals

[jods4]

This is a proposed optimization to the Vue compiler

What?

I suggest that Vue compiler should detect if a bound value is a constant (i.e. an array or an object literals whose values are themselves only constants) and hoist those values into const variables.

For instance, consider this template:

<div :title="a" :class="{ r: true, g: true, b: false }" />

Here's the current and suggested compiled render functions:

// Current PROD build

const __sfc__ = {
  __name: 'App',
  props: { a: String },
  setup(__props) {
    return (_ctx, _cache) => {
      return (_openBlock(), _createElementBlock("div", {
        title: __props.a,
-       class: _normalizeClass({ red: true, blue: true, green: false })
      }, null, 8 /* PROPS */, _hoisted_1))
    }
  }
}

// Suggested compiled code

const __sfc__ = {
  __name: 'App',
  props: { a: String },
  setup(__props) {
+   const _hoisted_2 = { red: true, blue: true, green: false };
    return (_ctx, _cache) => {
      return (_openBlock(), _createElementBlock("div", {
        title: __props.a,
+       class: _normalizeClass(_hoisted_2)
      }, null, 8 /* PROPS */, _hoisted_1))
    }
  }
}

This shouldn't require a lot of work, as analyzing bindings for "const-ness" is already performed by Vue compiler to support hoisting elements. Remove the title binding in this example and the whole div is hoisted!

Why?

For perf, of course.
This has two benefits:

1. It makes the render function faster, as it doesn't need to allocate and init an object every time it runs. It simply re-uses cached instances.
2. It can avoid unnecessary re-renders. Inside Vue, objects are compared by reference, not by value. If you bind an object literal to a directive or component props, every time the template renders, Vue thinks that the props value has changed (well, actually it has changed: it's a new instance!). So even though the values are all the same, this will trigger an update of the directive, or an update of the component.

When?

This can be more common than you'd think, for example:

• A directive that takes more than a value, will almost always accept an object of options. Sometimes those options are static.
• The recently released motion-v library is using complex props that are constant object literals 90% of the time.

And in my experience I see almost nobody "manually" hoisting theses options into setup constants, i.e. writing:

<motion.div :initial="divInitial" />
instead of:
<motion.div :initial="{ scale: 0.8, opacity: 0 }" />

[edison1105]

I think this would be better.

const __sfc__ = {
  __name: 'App',
  props: { a: String },
  setup(__props) {
    return (_ctx, _cache) => {
      return (_openBlock(), _createElementBlock("div", {
        title: __props.a,
+       class: _cache._hoisted_2 || (_cache._hoisted_2 = _normalizeClass({ red: ctx.foo, blue: true, green: false }))
      }, null, 8 /* PROPS */, _hoisted_1))
    }
  }
}

[jods4]

For sure!
This is an edge case because I bound class, which introduces an internal _normalizeClass call. I did not want to complicate things too much -- and it's not relevant to most props -- but if it could be handled by compiler that would be even better, I agree.

[jods4]

Another example I noticed today where this kind of optimization might kick in more often than not: ThresJs.

[jacekkarczmarczyk]

Is there a reason for not compiling it to

+   const _hoisted_2 = { red: true, blue: true, green: false };
 const __sfc__ = {
  __name: 'App',
  props: { a: String },
  setup(__props) {
   return (_ctx, _cache) => {
      return (_openBlock(), _createElementBlock("div", {
        title: __props.a,
+       class: _normalizeClass(_hoisted_2)
      }, null, 8 /* PROPS */, _hoisted_1))
    }
  }
}

That would allow to use literal constants for example in defineProps.

(Actually in this particular case _normalizeClass call could also be moved outside the component)

Also what about functions? It should be technically possible to detect whether function is using component's variables.

[jods4]

Do you mean like :title="foo(32)"?
It's more tricky because functions might not be pure: the returned value could be different on each invocation, in fact foo could access reactive state internally.

[jacekkarczmarczyk]

I meant more something like

<Foo @input="() => console.log('input')" :callback="() => console.log('callback')" />

and hoisting the following

      onInput: _cache[0] || (_cache[0] = () => console.log('input')),
      callback: () => console.log('callback')

You don't need to check if the function is pure. You only need to check if function is using component's data, which, if I understand proposal correctly, you have to do it anyway for objects literals, you can hoist :foo="{ foo: true }" but not :foo="{ foo: isFoo }" unless isFoo is not a component data, it might be imported. Idk internals so no idea if checking this for object literals would be much different from checking the function's body

One more thing regarding the proposal itself, objects passed to child components might be modified there, the resulting behaviour potentially might be different if you leave it as is vs hoisting on component level vs hoisting on the top level.

[jods4]

Ok I see what you mean now.
Yeah, given that the compiler already performs the caching when using @ it would make sense to do the same when binding a lambda with :.

One more thing regarding the proposal itself, objects passed to child components might be modified there, the resulting behaviour potentially might be different if you leave it as is vs hoisting on component level vs hoisting on the top level.

It is true that this results in a change in behavior:
Today props bound to literal values change with every render of parent component. This triggers the child component rendering, and it also means that a fresh copy is seen each time (if the component had modified the bound value).
As with all changes, I'm sure one can devise an example that breaks but I can't think of anything that wouldn't be bad practice. A child component shouldn't know when its parent will render, and mutating an object when you constantly loose your changes seems useless?