[composition class] Component setup using ES6 class works out of the box in Vue 3, why not officially support it!

[sreenaths]

I just discovered that we could use ES6 class for creating components instead of the Composition API setup function. The best thing is it works out of the box in Vue 3 without any dependency on vue-class-component or other libraries! Even the experimental template interpolation service in Vetur is working flawlessly with it!!!

Surprisingly I couldn't find this way of creating components in any of Vue 3 documentation. Not sure why, or am I missing something!?
With official support, we could make the experience even better.

Why use ES6 class:

In the current way of creating a component using setup function & composition API, users are encouraged to create closure functions. When the number of instances of a component is minimal this doesn't make much difference. But when there are so many instances of the component, multiples of those many functions objects would be created, which doesn't look ideal.

For instance, 1000 instances of the following component would create 1000 getUserRepositories function objects. Which is overkill.

import { fetchUserRepositories } from '@/api/repositories'
setup (props) {
  let repositories = []
  const getUserRepositories = async () => {
    repositories = await fetchUserRepositories(props.user)
  }
  return {
    repositories,
    getUserRepositories
  }
}

What does the proposed API look like?

This is how we could create a Counter component using ES6 class & composition API. And it works with the current release of Vue 3!

<template>
  <div class="counter">
    Counter: {{ valueInternal }}<br />
    <button type="button" @click="onAdd">Add</button>&nbsp;
    <button type="button" @click="onSubtract">Sub</button>
  </div>
</template>

<script lang="ts">
import { defineComponent, ref, Ref } from "vue";

class Counter {
  valueInternal: any;

  constructor(val: number) {
    this.valueInternal = ref<number>(val);

    // Guess the following hack is needed because of hasOwn check @ https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/componentPublicInstance.ts#L293
    // We must be able to remove it with official support
    Object.assign(this, {
      onAdd: this.onAdd,
      onSubtract: this.onSubtract
    });
  }

  onAdd() {
    this.valueInternal++;
  }

  onSubtract() {
    this.valueInternal--;
  }

  someOtherMethod() {
    // Statements
  }
}

export default defineComponent({
  props: {
    value: Number
  },
  setup: props => new Counter(props.value || 0)
});
</script>

I have committed a dummy project with working example @ https://github.com/sreenaths/vue3-composition-class

What could we do through official support:

There could be more, but the following are some of the items that came to my mind.

1. Direct default export of the class from inside the script tag. export default Counter instead of this working snippet export default defineComponent(props => new Counter(props));.
2. Some way to bypass hasOwn check explained above in Counter constructor so that inherited properties can be accessed from inside the template - Can we use decorators for that?
3. Should we have an interface for type-checking?
4. When directly exporting the Class, can we provide some way to pass props definition?
5. Documentation.

vuejs/core#3373 - This is the issue that I originally created for this discussion

[LinusBorg]

For instance, 1000 instances of the following component would create 1000 getUserRepositories function objects. Which is overkill.

As explained in the original issue, that advantage will be pretty much non-existant with your proposal as class methods need to be bound so they can be passed around, i.e. for event listeners, provide() or many other use cases:

class Store {
  constructor() {
    this.data = 'hello'
    Object.assign(this, {
    setData: this.setData
    })
  }
  
  setData(v) { this.data = v }
}
const store = new Store()
const setData = store.setData
setData('goodbye') // TypeError: Cannot set property 'data' of undefined 

console.log(store.data) 

With bind:

class Store {
  constructor() {
    this.data = 'hello'
   // creates a new function object in memory
    this.setData = this.setData.bind(this)
  }
  
  setData(v) { this.data = v }
}
const store = new Store()
const setData = store.setData
setData('goodbye') 

console.log(store.data)  // => 'goodbye'

[LinusBorg]

Looks like there is some confusion regarding how function call works in Javascript!
To use handleClose in the same SFC, you just need to use <myComponent @close="handleClose"> myInstance is not required.

Ha, good catch.

That's not so much about how JS function calls work, though., It's about how Vue works around that problem for you (which I actually forgot about, hence my wrong explanation before) - by creating another function that invokes your handler with apply ensuring the correct this context.

This is a snippet of the render function for the component you linked to:

onClick: _cache[1] || (_cache[1] = function () {
      return _ctx.onAdd.apply(_ctx, arguments);
    })

nontheless, you're correct - usage with v-on is not actually an issue.

It's an issue if you want to use it with watch or computed, though:

class Counter {
  constructor(val) {
    this.valueInternal = ref(val);

    // Guess this is needed because of hasOwn check @ https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/componentPublicInstance.ts#L293
    // We must be able to remove it with official support
    Object.assign(this, {
      onAdd: this.onAdd,
      onSubtract: this.onSubtract,
    });

  //  TypeError: Cannot read property 'valueInternal' of undefined
    watch(this.valueInternal, this.someOtherMethod)
  }

  onAdd() {
    this.valueInternal++;
  }

  onSubtract() {
    this.valueInternal--;
  }

  someOtherMethod() {
     console.log(this.valueInternal)
  }
}

Here, you will need to wrap it in another function:

watch(this.valueInternal, () => this.valueInternal.value++)

So when using it with watch and computed, you don't actually save anything, you might end up creating an additional function compared to a simple inline watch() in a traditional setup definition.

I say this while fully acknowledging that there would be less function instances overall. I just cautiously say that you might both overestimate the actual impact on performance and underestimate the potential issues that yet another abstraction / way of doing things could come with.

I could imagine documenting this in the cookbook as a pattern for performance-critical usecases, provided that we end up seeing real-world benchmarks where this pattern actually proves to show significant impact on perf.

But I don't see it as something in Vue core.

PS: Hope that doesn't mean we shouldn't optimise what we can.

We should optimize what makes sense, given all the different constraints, priorities, expectations etc in a project such as Vue. There's such a thing as premature /over-optimization.

One thing that you are missing here is that all setup functions are already using classes!

The hasOwn check that you identified as a problem for your approach exists precisely because we don't want to expose the prototype methods of an object instance to the template - those are not part of the API.

Technically my request is simple:
Please support objects of all types in setup return, and for that please make setup function acknowledge the prototype chain of the returned object! Not sure why that might be a tough task!

There's a difference between solving your hasOwn issue to make this work (smother than it already does) on a technical level, and adopting it as a recommended pattern in docs etc. I was under then impression we are not just talking about the former, but the latter?

As mentioned above, the hasOwn check has the job of not exposing the setup object's own instance methods (hasOwnProperty, toString() ...) to the template as strictly speaking, that's not part of its API.

All of this is surely debatable but not there for no reason whatsoever.

[jods4]

@LinusBorg Can we debate this point a bit?

The hasOwn check that you identified as a problem for your approach exists precisely because we don't want to expose the prototype methods of an object instance to the template - those are not part of the API.

Let's put aside the performance argument for now.

I think that at one point some users will try to return state based on a class (well, @sreenaths already did).
To that my reaction is: why not?
Someone familiar with OOP could be led this way wanting to use a base class to share behaviour between several components, instead of say functional composition.

That hasOwn check is a bit of a roadblock here.
Can we discuss why it's really required, rather than say a simple in check?

The Object prototype members do not impact the view unless you actually want to use them.
And if I write the following in my template, I think it's because I intend it:

<!-- Imagine this view is in a higher-order component that might receive dynamic state objects -->
<div v-if="hasOwnProperty('vip')">VIP</div>

It seems that checking own properties hinders advanced scenarios more than it enables or protects.

Components are generally in control of what they use for state so in the hypothetical case where you don't want to expose any prototypical members, you could use Object.create(null) or { __proto__: null } for your state.

A further, long-term goal could be to enable (optional) class-based components. You can kind of do it already, but stuff like hasOwn are the small papercuts that make the idea not great.
This could be a Vue programming style (replacing defineComponent + setup):

export default 
@component
class {
  firstName = "John",  // reactive, as if it was a ref
  lastName = "Doe",
  @computed get fullName() { return this.firstName + this.lastName }
}

To be honest I personally will stay away from decorators until they're real, but it gives idea.
For simple components it's a nicer programming style than setup() (<script setup> aside), it avoids Ref .value and can be implemented in a more performant way internally.

Not pushing towards that in any way, but somebody in the community might want to try to innovate in that space and stuff like hasOwn are inhibitors.

[sreenaths]

I could imagine documenting this in the cookbook as a pattern for performance-critical usecases, provided that we end up seeing real-world benchmarks where this pattern actually proves to show significant impact on perf.

I have committed a quick performance comparison check @ sreenaths/vue3-composition-class@73a6741

And here are the results, they are consistent every-time I run (Memory in bytes):

• Class implementation (with 12 methods) is using 18% less memory than function implementation.
• I even tried with just 2 methods, class was using 5% less memory.

It's a production build. Hope this proves that for complex components class is better. Closure/function uses more memory with larger or more number of methods.

PS: Thanks to JIT, time taken is not much different. Class is better just by few milliseconds.

[sreenaths]

@LinusBorg

onClick: _cache[1] || (_cache[1] = function () {
return _ctx.onAdd.apply(_ctx, arguments);
})

This is nice. Thanks for sharing.

So when using it with watch and computed, you don't actually save anything, you might end up creating an additional function compared to a simple inline watch() in a traditional setup definition.

Totally, agree. That said

• They would work perfectly from Options API watch & compute
• Composition API watch() options could support it by adding a context property. But probably too much to ask 😬

I could imagine documenting this in the cookbook as a pattern for performance-critical usecases, provided that we end up seeing real-world benchmarks where this pattern actually proves to show significant impact on perf.

Thanks, that would be great.

As mentioned above, the hasOwn check has the job of not exposing the setup object's own instance methods (hasOwnProperty, toString() ...) to the template as strictly speaking, that's not part of its API.

Ha, I see.
What might be the best way to expose some specific methods. Wouldn't that need some core change. Object.assign doesn't looks elegant. Please suggest if there is an alternative.

[LinusBorg]

@jods4 I'm not overly attached to hasOwn personally, though I'm not sure if there's more to it that Evan might know, as to why it's there.

@sreenaths thanks for the benchmark. I played a bit with it yesterday evening and attempted to get numbers for a more realistic scenario:

https://github.com/LinusBorg/vue3-composition-class/blob/realistic-example/src/components/Counter.vue

Yours is still geared towards overemphasizing the relative overhead of closures vs. classes as the benchmark app renders little to no elements and has no reactive data except for one ref, but 12 functions that don't really do anything.

So i took some of those dummy functions and used them to implement a minimalistic todo list example in each counter component, including a computed, a watch, a couple of todo objects etc., along with a template to match it

that alone brought the absolute mem of the app from ~32 MB to ~130MB, it basically quadrupling the mem usage. The absolute overhead of the closure approach compared ot the class-based approach stayed practically stable, of course, around 4-5MB, which means now it sits at ~4% comapred to your 18% - and we still have 7 of those 12 functions essentially doing nothing, whereas in a more realistic scenario, these would likely also have some data connected to them or some part of the template associated with them that would lead to more absolute memory usage, further reducing the relative impact of the closures on mem usage.

Concerning rendering performance, the app now takes around 4,0-4,2 seconds to render on my machine, compared to ~350ms before oni my machine. Here, we now end up with a ~300ms advantage of the class-based approach. But in relative terms, blocking the main thread for 4 seconds is a no-go either way, so Vue's core performance would become a problem long before the difference between the two discussed approaches would.

General sidenote: on my machine, numbers fluctated pretty heavily, I also had occasional runs where the two were practically identical in perf, for example, and your mem measurment often flaked and have weird negative numbers, so I largely focused on the absolute memory from devtools.

---

All of this doesn't negate that there is a noticable impact when rendering a very high number of components, but as shown the relative mem overhead isn't that much in apps that have real workloads and template sizes, and the perf improvement is noteworthy, but likely not an issue before Vue ore itself becomes one.

So as I assumed previously, it's an improvement, but one that likely only has an impcat in rather extreme scenarios, and could be documented as a recipe for such scenarios.

To me personally it's not impactful enough to do a 180 and make this a core pattern that we actively recommend, mostly because it comes with an new set of challenges / different patterns to work with when using it in more complex scnerarios where you want to / need to do a lot of composition.

[backbone87]

imho the idea is quite compelling, but needs to be fleshed out a little bit.

performance

the pure techinal benefit is the performance gain you mention, but your example is a bit idealized for your argument. you would only see this kind of memory gain, if you have few components with LOTS of uses on a single render tree. but usually you have a LOT of different components a few times in the same listing. there are components that get used many times in a single render tree, but these are few and the ratio to the "unique" components is not that high and additionally, from my experience, the few components that indeed get used many times in a single render are usually the ones with few methods/computeds. same goes generally regarding time performance, but there you have the additional benefit of "recreated" instances that give a little more weight to the class case. so if performance should be an argument, it must be a less idealized and more realistic scenario used for the "prove".

for what is this an alternative?

i think using classes in the setup in the way presented here is an anti-pattern, because the main benefit of setup was meant to be composibility. yes ofc you can build small classes and compose a hierarchy, but this would diminish performance gains in real world use cases even more, since you just instantiate the same amount of classes as you would produce functions. also my guess is that writing up classes is more lines of codes then writing out some functions.

instead i would argue this is more a replacement/alternative to the options API, if you go "all the way" for classes:

export default defineComponent(class Counter {
  public static props = {
    value: Number,
  };

  public static setup(props): Counter {
    const counter = new Counter();
    counter.valueInternal = ref(props.value ?? 0);

    return counter;
  }

  private valueInternal: Ref<number>;

  @Bind()
  public onAdd() {
    this.valueInternal.value++;
  }

  @Bind()
  public onSubtract() {
    this.valueInternal.value--;
  }

  private someOtherMethod() {
    // Statements
  }
});

while i find this more appealing then a big object, it is basically still the same as vue-class-component, which works in vue 3.

[sreenaths]

Thanks @backbone87. Really like your take on the idea. Especially that setup function.

Why class made sense to me

I was trying to create a table component where each cell is a sub component, and the number of cells could go up to 10,000 on average. Then classes totally made sense. But again, as you sad in the first paragraph, usually you have a LOT of different components a few times in the same listing looks like a more common scenario, and classes might not make a big perf difference to everyone.

Why am I staying away from vue-class-component for the time being

I had been using vue-class-component + vue-property-decorator with Vue 2. And then Vue 3 landed. I was starting my Vue 2 to 3 migration and to my surprise discovered that vue-property-decorator is not compatible with Vue 3. vue-class-component alone didn't look elegant enough, and the new defineComponent gave the type check I needed; so finally I ended up re-writing all my components using Options & Composition API. As that happened, I prefer to go with the most bare bone solution.

Now that I have stumbled on the fact that plain ES6 class can be used, Im not sure if I would need vue-class-component.

At the least, would it be ok to ask for the setup function to acknowledge the prototype chain of the returned object!?

[backbone87]

leaving aside the technical implications of checking the prototype chain, i think it should be fine. the return value of setup is meant to represent the state of the component and i dont see any particular reason, why that shouldnt be a class instance.

[jods4]

@backbone87

but your example is a bit idealized for your argument. you would only see this kind of memory gain, if you have few components with LOTS of uses on a single render tree but usually you have a LOT of different components a few times in the same listing. [...] from my experience, the few components that indeed get used many times in a single render are usually the ones with few methods/computeds.

Do you have data to back up this claim?
It immediately comes to my mind that most applications are built on top of a components framework, e.g. Vuetify, Quasar, or maybe home-made.

• Those have components for every textbox, button, etc. and are poster-child examples of components with lots of use in the render tree.
• Because they are general-purpose, they tend to have lots of methods and computeds, just look at their documentation for all the props they accept.

If those libraries could get a 4x memory and 2x speed improvement that would actually be huge.

[backbone87]

i didnt say it has no performance gain, just that his demo case was idealized for his argument. and since the same can be achieved by using classes as "non-root" of setup return values (e.g. { counter: new Counter() } works just fine iirc), i think his performance argument doesnt support his proposed idea very much (and i like the general direction of his idea).

[jods4]

You might be interested in looking at this where I explored how much this you could actually use in Vue 3 without going crazy:
#168
(A few details have changed since I wrote this, which makes it works slightly better today.)

Answer is actually quite a lot. This looks even nicer if instead of defineStatefulComponent you use a class.
You can even take it further and get rid of ref and .value in your code + optimize the reactivity storage (briefly: create a non-proxy based reactive object; also: more efficient disposal code for watchers and computeds).

Today I see only one big downside to this programming model: to be perfect it really needs decorators, which after 6+ years are still... let's say far from done. That's quite a bummer to me.

The aversion of some prominent JS figures towards classes is IMHO misplaced. The are a pretty good tool to build UI, as demonstrated by the many existent UI frameworks. It'd be nice if they got some support in Vue 3 Composition.

If you squint a bit, script setup looks like class-envy. At a high level much of what it does is a given if you use a class.

[lzxb]

Use class style to write setup and support vue2 and vue3

https://github.com/fmfe/vue-class-setup

[zhennann]

Hello everyone, I have created a vue3 framework with ioc container, named as Zova.

You can find it here: https://github.com/cabloy/zova

Do you agree with such a concept: Class should not be used in the view layer, but in the business layer.

Therefore, it is completely different from vue-facind-decorator or vue-class-component that the Vue3 setup syntax sugar is still used to define vue components (such as props and emits of components), and ioc container and class are introduced only at the business level. In this way, combine the advantages of the two (function/class) to make the code more concise and elegant.

Zova has a very important feature: With the support of ioc container, defining reactive states no longer needs ref/reactive. Without ref, naturally there is no need to write a lot of ref.value.

Demonstration: no ref/reactive, no ref.value

1. Define reactive state

Define a reactive variable count in the component and add two methods to modify its value

export class ControllerPageCounter {
  count: number = 0;

  increment() {
    this.count++;
  }

  decrement() {
    this.count--;
  }
}

2. Use reactive state

Use count in render class

export class RenderPageCounter {
  render() {
    return (
      <div>
        <div>count(ref): {this.count}</div>
        <button onClick={() => this.increment()}>Increment</button>
        <button onClick={() => this.decrement()}>Decrement</button>
      </div>
    );
  }
}

Demonstration: dependency injection

1. Logic Reuse

Create a Counter Bean to implement the logic of count

@Local()
export class Counter {
  count: number = 0;

  increment() {
    this.count++;
  }

  decrement() {
    this.count--;
  }
}

2. Inject and use in a component

export class ControllerPageCounter {
  @Use()
  $$counter: Counter;
}

export class RenderPageCounter {
  render() {
    return (
      <div>
        <div>count(ref): {this.$$counter.count}</div>
        <button onClick={() => this.$$counter.increment()}>Increment</button>
        <button onClick={() => this.$$counter.decrement()}>Decrement</button>
      </div>
    );
  }
}

[Super-Chama]

Very cool, love the angular aspect of this. IoC is something I always missed when migrating from angular to vue.