Deprecate vue-class-component

[Mikilll94]

Here you can read a post from Evan You @yyx990803 vuejs/core#4744 (comment)

I feel like this library is not maintained anymore. Maybe it's time to deprecate it?

vue-class-component made sense for Vue 2.x when the TypeScript support was really bad. Currently this library provides no additional benefits, it just modifies the syntax of declaring a component. Additionally almost all users of vue-class-component are using vue-property-decorator (https://github.com/kaorun343/vue-property-decorator) which also seems abandoned.

For Vue 3.x the author of vue-class-component @ktsn introduced a new way of declaring props in a component #465 which IMO looks really ugly and most developers will not like it. This creates additional chaos in the Vue ecosystem because now you can use the new way of declaring props for class components or just install vue-property-decorator and use decorators like it was before. Additionally you can also use normal Options API or Composition API.

In conclusion, my suggestion is to deprecate vue-class-component and do not further suggest new developers using it.

There is no point to fragment the Vue ecosystem into class components and object components where class components provides no gain over the standard Vue syntax.

[r-priyam]

I don't really think that it should be depreciated, As Evan said, Its depreciation will depend above use cases and I am using it in the 2nd last release 3.2.19 and it still works like a charm. I agree with the blind rumor that it's not maintained anymore but still no words from the core maintainer (@ktsn) that what is his plans, to continue with this or not. So directly asking for depreciation doesn't make sense at all.

[Mikilll94]

@r-priyam
I agree that this library works really well with Vue 2. But I think it has completely no sense for Vue 3 (especially with the strange syntax from here: #465)

[Maia-Everett]

I, for one, would prefer someone to take over maintainership. I would hate to see vue-class-component die, as I love the object-oriented syntax (coming from desktop GUI toolkits like Swing and Qt) and use vue-class-component in all my personal Vue projects.

[Tarang]

I disagree with the logic where the primary motivation to deprecate it is to reduce the options available. The library does make it simpler.

[jimhucksly]

I like too to use this library. Don't deprecated this

[andrewpayment]

Just my two cents as someone learning Vue for the 2nd time (the first experience being a freelance project in 2015). So, take this with a grain of salt if you'd like.

I have an extensive background in AngularJS & Angular and designed an enterprise solution for the company I work for in Angular. I would like to blend in some Vue and bring my own Vue knowledge back up to see if we are missing anything so I've been working on an internal tool with Vue 3.

I'm only a few hours into this project and really just getting my feet wet, but I can tell you from an outside perspective the Vue ecosystem already feels extremely fragmented. With that being said with the continued dominance in the marketplace with TypeScript it seems like the community would be missing out big time by deprecating this project. I have been going back and forth between writing components in Options API and Composition API and they're so maniacally similar that it's painful to discern the differences as a novice, but I also am not sure which is better and honestly I don't really know most of the pros and cons because they seem so subjective from everything I've read from the community so far.

I think a distinctly different coding paradigm like class declarations reaches out to a much larger sect of potential Vue developers. It specifically leans into TypeScript support and class declarations are significantly cleaner in TypeScript than handling either the Options or Composition APIs while trying to craft Vue components from my experience so far. It's understandable that some might not find it necessary but it seems like class components offer a much different experience with better TS support than either Options or Composition, and ultimately have gotten my attention solely based on the fact that I'm very comfortable with TS classes.

I am going to try this library out and hope that my comments are considered because I think the learning curve for Vue is much steeper than it used to be because the different style options of writing Vue code now feel very similar but extremely nuanced and to be honest a bit frustrating sometimes to parse through which I should even use in a project.

[dennmat]

There are other great arguments in here.

May not need to be deprecated as it looks like, from Googling, everyone that is trying to continue using class based components in Vue 3 are just hitting road block after road block which is a shame.

Classes offer a lot of benefits, speed and memory usage being some of them, and I understand there are issues(that could be solved with time and effort IMHO, but that's up to the maintainers to decide).

To me the biggest and arguably the most important is legibility. Maybe it's from my background or not, but reading a nicely formatted class in code is quick, painless, easy to re-structure, easy to parse and reason. Where as the other APIs are effectively like staring at giant JSON blocks and are painful to parse and reason about. I don't want to code in webpack configs.

I'll be sticking to Vue 2. And it looks like a lot of others will be as well. This is reminiscent of the Python 3 situation, the community was fragmented and they had to drag out support for 2 for way longer than ever intended. They may want to reduce the surface area as another said, but this will likely just drag out the life of 2 well past its intended life. It's not an insignificant amount of users that want this as can be seen by the usage statistics of vue-class-component and vue-property-decorator.

[hmmdeif]

I spent the past couple of days refactoring vue-class-component and vuex counterpart out of my Vue3 project and replaced it with the Composition API. Not only did I reduce code size, I reduced complexity, removed workarounds that I had to use due to vue-class bugs, and I think it's more legible than before.

Typescript works perfectly fine in Vue without the need for classes and I made this comment after finally deciding to refactor a medium-ish sized project as I came up against one too many roadblocks from using this project. I would recommend all readers to not worry about dropping vue-class-component as it was pretty simple to do. And the bug I hit resolved itself too by losing this dependency. You don't need classes to write good Vue code and have good Typescript support,

[ImBoop]

reduced complexity, removed workarounds that I had to use due to vue-class bugs, and I think it's more legible than before.

This seems rather opinionated -- my codebase which utilizes class components has reduced complexity, and code introspection is a lot faster and less difficult with class-based components.

With JS moving towards more and more classes (e.g. custom elements, etc), fully dropping support for class based components will do more harm than good for Vue and will push a lot of people towards Angular I think.

I'd sooner prefer to see vue-class-component get properly supported (as as you have mentioned, bugs with it tend to get ignored or downplayed.)

Vue 2 had great class support, I'm not sure I see the point of abandoning this fantastic way of using Vue which has many benefits such as reduced typing, improved organization (at least IMO), improved readability (albeit, this was with TS annotations that only works in Vue 2, another pain point with moving to 3) etc.

[hmmdeif]

This seems rather opinionated -- my codebase which utilizes class components has reduced complexity, and code introspection is a lot faster and less difficult with class-based components.

That's fair. I more meant in the meantime, considering the lack of maintenance for this project, that for some projects it might be worth considering dropping the dependency.

[ImBoop]

This seems rather opinionated -- my codebase which utilizes class components has reduced complexity, and code introspection is a lot faster and less difficult with class-based components.

That's fair. I more meant in the meantime, considering the lack of maintenance for this project, that for some projects it might be worth considering dropping the dependency.

I'll be honest, vue class components is what won me over with vue. I guess ultimately I'd appreciate it most if Vue would come out with a stance regarding this because it being in limbo does no one favors.

Im optimistic!

[Maia-Everett]

I spent the past couple of days refactoring vue-class-component and vuex counterpart out of my Vue3 project and replaced it with the Composition API. Not only did I reduce code size, I reduced complexity, removed workarounds that I had to use due to vue-class bugs, and I think it's more legible than before.

Purely personal opinion, but the Composition API, especially <script setup>, is full of edge cases that make writing straightforward components unwieldy. You have to reason about different semantics, whereas vue-class-component is purely a different syntax for the Options API's semantics.

There's one particular edge case that has kept me on vue-class-component: beforeRouteEnter in components. There is simply no equivalent of it in the Composition API, so you can't just write the function in <script setup>; instead you have to write an empty Options API component definition so you can stick beforeRouteEnter somewhere, and then TypeScript won't let you refer to the component type inside the function because it doesn't consider it a type. Writing the same code with vue-class-component is very straightforward in comparison.

[agileago]

i make the https://github.com/agileago/vue3-oop to use class component in vue3. and its feature is class + tsx + di .

[ruojianll]

In my opinion, Composition API is a compromising plan to make it compatible with VUE 2's plain object component for resolving logical concerns problems. The class based components could resolve the problems perfectly and more elegant with JS or TS decorators. VUE 3 is also designed in TS and classes, so class based components should be first-class citizen in VUE 3 natively as default option.

And more, JSX as a general template language has a well supported type system in TSX and a large number of users. Class based components and TSX is the best practice for me.

[bolerio]

The lack of a firm decision on this one from the maintainers (@ktsn ?) is making difficult for users to make design decisions for their projects. In our case, we very much like this component and would like to use, but if it's not going to be maintained we won't. And we are at a point where we have to review/rewrite a big chunk of the app and needs to decide what style of component writing to adopt. We are stuck not knowing if we should invest time in vue-class-component or not.

Otherwise, I hereby am thumbs upping everyone here who expressed support to keep this component alive. vue-class-component based code is so much more elegant and readable than the new APIs.

[ImBoop]

The lack of firm commitment from the Vue team one way or another makes it really hard to know what direction to move in. For the time being, I'll continue using Vue 2.

[agileago]

i think vue3 is native support class component. you can easily wrap vue3 to vue class component. for example https://github.com/agileago/vue3-oop. it is very easy to use. some example below.

1. define component

import {
  Autobind,
  Component,
  ComponentProps,
  Computed,
  Hook,
  Link,
  Mut,
  VueComponent,
  VueService,
} from 'vue3-oop'
import { VNodeChild } from 'vue'

// general component define
class Count extends VueComponent {
  @Mut() count = 1
  @Autobind()
  add() {
    this.count++
  }
  render() {
    return <div onClick={this.add}>{this.count}</div>
  }
}

2. define component with props

// component with props
interface Count1Props {
  size: 'small' | 'large'
  onClick?: (name: string) => void
  slots: {
    item(name: string): VNodeChild
  }
}
class Count1 extends VueComponent<Count1Props> {
  static defaultProps: ComponentProps<Count1Props> = ['size', 'onClick']
  @Mut() name = 'count1'
  @Mut(true) shallowRef = {}
  @Computed()
  get computedName() {
    return this.name.toUpperCase()
  }
  @Hook('Mounted')
  mounted() {
    console.log('mounted')
  }
  @Link() div?: HTMLDivElement
  render() {
    return (
      <div onClick={() => this.props.onClick?.(this.name)} ref="div">
        <div>this is size {this.props.size}</div>
        {this.context.slots.item?.(this.computedName)}
      </div>
    )
  }
}

3. define reuse service like useHooks

// reuse service like use hooks.
// you can use it in component like
// countService = new CountService
class CountService extends VueService {
  @Mut() count = 1
  add() {
    this.count++
  }
}

4. use DI(injection-js) in component with service

you can use service without di. just like countService = new CountService()

@Component()
class Count2 extends VueComponent {
  constructor(private countService: CountService) {
    super()
  }

  render() {
    const { countService } = this
    return <div onClick={() => countService.add()}>{countService.count}</div>
  }
}

[Ybbbb]

真心希望这个库可以继续维护，面向对象式的语法写起来真的很舒服

[bolerio]

@angelhdzmultimedia Very well put and I sincerely applaud you! Any form of fanaticism is silly and laughable, including in "high tech" (if a GUI framework can be considered high tech these days). What attracted me to vue initially as opposed to rival framework was to a large degree the spirit of practicality and simplicity. If you are right, seems like all of that is going down the toilet, very disappointing.

[wilfred-asomanii]

This is my first time learning Vue and I must say I'm very disappointed by this. It's not immediately clear to me as a newcomer which API to use. The Vue docs only offer Options and Composition APIs but strangely enough, the VueCLI created my first project with class components v8, of which I can find no documentation. Then I later realize that VueCLI is in "maintenance" mode... sigh 🤦🏽‍♂️

[TechWatching]

That's true there are different options but the vuejs documentation explain each one and why choose one over the other. Moreover the quick start in the documentation mentions to use the create-vue scaffolding tool.

[ruojianll]

I set up a repo to do this work in vue3.
https://github.com/facing-dev/vue-facing-decorator

[ruojianll]

I set up a repo to do this work in vue3. https://github.com/facing-dev/vue-facing-decorator

First release.
https://www.npmjs.com/package/vue-facing-decorator

[bolerio]

That's great @ruojianll , thanks for picking up the maintenance of this!

[ruojianll]

1.0.3 release with many features.
https://github.com/facing-dev/vue-facing-decorator

[ThreeScreenStudios]

@ruojianll Thanks for opening the new repo, will start looking at switching over to this!

[ruojianll]

@bolerio @ThreeScreenStudios Thank for your attention. The basic features almost finished. Please tell me what you need or contribute to it.

[rootux]

@ruojianll Thank you for this library - would love to see an example of inheriting your Base class and another class (Using mixins?)
In my case my class already inherits a component (Quasar) class

[ruojianll]

@rootux You could use @Component({modifier(){}}) to alter the option what you want.

[lzxb]

If anyone likes it, I will continue to maintain it

[lzxb]

You can only write code in setup, but every time you execute the setup function, you will create a class. Two script tags are used to solve the problem of class reuse.

[lzxb]

Our company has a very large-scale vue class component project, and we plan to replace it with vue class setup, which will bring better typescript support.

[lzxb]

You can only write code in setup, but every time you execute the setup function, you will create a class. Two script tags are used to solve the problem of class reuse.

Thanks for the explanation.

But if we are going to use Class Based Components, it's to use the classes, not the setup function, so we wouldn't need the <script setup>. I think I'm gonna stick to https://github.com/facing-dev/vue-facing-decorator.

Can it normally identify the types of component props?

[ruojianll]

@lzxb I prefer jsx than template in SFC. Syntax in template in SFC is ambiguous such as <div @click="foo()"></div> is same to <div @click="foo"></div>. It's not support write logical in template such as <div>{foo.map(ite=>ite.bar).map(bar=><p>{bar.toString()}</p>)}</div> in jsx.

In vue-facing-decorator we can use it with tsx. That supports props types and event types. https://facing-dev.github.io/vue-facing-decorator/#/en/tsx/attribute-types/attribute-types?id=usage

[chanon]

I have been very successfully using Vue2 + vue-class-component for many years in production.

Now on my next project I'm evaluating Vue3 vs. other options.

Deprecating vue-class-component, forcing to write in bare 'functions' instead of classes, I feel is a big loss. I agree with the many comments above about the many reasons why this is a bad decision.

For me this is a very big loss as without class support it completely changes the way I can easily and quickly write maintainable UI code. Additionally together with the fact that React currently has a ton more usage in general in the industry and also has React Native, it means I am probably going to go back to React. This is extremely sad for me as I have been advocating Vue over React for years.

I see there are community projects to fix this, but without official support I don't feel confident enough to build a codebase on them.

[TheBojda]

@ruojianll vue-facing-decorator is very promising. I think this is the way. As this thread shows, many developers would use Vue this way. If this repo (vue-class-component) is really deprecated, and nobody would maintain it, then you should be the maintainer, and you should move the content of vue-facing-decorator to here, and continue it here as a next version of vue-class-component. I think the current maintainer (@ktsn ) and the @vuejs community would be open to it. You should contact them.

The problem with vue-facing-decorator is that hard to find it. I would never know about it if I don't search in Google directly to the deprecation of vue-class-component, and I don't find this thread.

[ruojianll]

@TheBojda I have created a PR(#616) to add vue-facing-decorator into readme.md but it is still in open.

[ruojianll]

@TheBojda I don't think they will accept vue-facing-decorator because class component is not recommend in vue3 otherwise this repo won't be deprecated.

[TheBojda]

Sad! But if it's really depricated, the repo should be archived, and a link to your project would be great.

Btw, I now porting my current project from vue-class-component to your vue-facing-decorator. ;)

[TheBojda]

You should also send your PR(#616 ) to vue-property-decorator. It looks also deprecated and used by many ppl.

[ruojianll]

Sad! But if it's really depricated, the repo should be archived, and a link to your project would be great.

Btw, I now porting my current project from vue-class-component to your vue-facing-decorator. ;)

@TheBojda My pleasure and I will create a PR to vue-property-decorator.

[chanon]

Nevermind, I found the docs for it:
https://facing-dev.github.io/vue-facing-decorator/

[hnviradiya]

Man. I hate vue now if this is deprecated. Composition API is no same even if it supports typescript. Composition API is almost unreadable code. It was this class-style component that was making it visually appealing.

[lzxb]

You can try it
https://github.com/fmfe/vue-class-setup

[viT-1]

This is my first time learning Vue and I must say I'm very disappointed by this. It's not immediately clear to me as a newcomer which API to use. The Vue docs only offer Options and Composition APIs but strangely enough, the VueCLI created my first project with class components v8, of which I can find no documentation. Then I later realize that VueCLI is in "maintenance" mode... sigh 🤦🏽‍♂️

Documentation is here

[brett-allen]

this is sad indeed...the Options API is utilitarian in look and feel, but the Composition API is very untidy: ref() and .value is very much a framework lifting its skirt because they couldn't think of anything better...until they dreamt up $ and $$ to ref and unref a property...very untidy indeed.
vue-class-component made Options API a little less shite and allowed me to avoid the complete shite of Composition API.

[hnviradiya]

this is sad indeed...the Options API is utilitarian in look and feel, but the Composition API is very untidy: ref() and .value is very much a framework lifting its skirt because they couldn't think of anything better...until they dreamt up $ and $$ to ref and unref a property...very untidy indeed. vue-class-component made Options API a little less shite and allowed me to avoid the complete shite of Composition API.

Yes. And for every function we have to write function prefix and its having its own scope, which is redundant in class componsnt. Without function we were able to access class properties directly with this statement.

[rdhelms]

I think @ruojianll 's vue-facing-decorator has a ton of potential...of all the alternatives to the original vue-class-component and vue-property-decorator configs that I've seen so far, that seems to work the best with our existing code with minimal changes. Has anyone else had a chance to check that out? I would love if we could come up with an official vue3 successor to these packages, since the maintainers here don't seem to be responding anymore

https://facing-dev.github.io/vue-facing-decorator/
#569 (comment)

[JavascriptMick]

I have a medium sized production codebase using vue-class-component and the property decorator (and vuex but thats incidental). I have everything How I want it, I can punch out features really fast and everybody thinks it's great. I was a supporter of the original RFP on a Class based syntax and was pretty cranky about it not getting up. I am also super frustrated by the splitting of the community and increase in startup complexity introduced by all the changes in Vue 3.

Having said that, I am using Nuxt 3 for a personal project (because SSR and SSO). I deliberately chose to use all the shiny things, composition api over options api, pinia over vuex. It was a very rough transition in my brain tbh and really not fun but at the moment, I have all of the new stuff working pretty good and I am reasonably productive.

In short, I think the horse has left the stable here. If we want Vue to be a robust framework with a strong community, I think we need to embrace the newer methods. Yes they do smell a little functionally, but it is still way better than react and nowhere near as silly as Angular. vue-class-component is a side road that was not taken a while ago and several new turns have been made since then. It's just not relevant.

At the end of the day, all of this BS arguing around and around just distracts from the real task of building real shit for real users. More side roads and options and dead ends in the framework just dilutes the current community and serves as a barrier to entry for new members to the community.

By the Same token, the individuals with leadership in the community need to quell their ADHD and stop changing every fucking thing every fucking major release. If Vue 4 has yet another way of doing things, you will kill the framework.

[WhatNot911]

Class components are argueably easier to read, we have a huge codebase written in class, and it neatly serves as a bridge for backend monkeys to every now and then come out to the frontend to create a component or fix something in a class than in any other API that looks alien to them. So keep your grubby hands off class components XD 🧡

[hnviradiya]

Class components are argueably easier to read, we have a huge codebase written in class, and it neatly serves as a bridge for backend monkeys to every now and then come out to the frontend to create a component or fix something in a class than in any other API that looks alien to them. So keep your grubby hands off class components XD orange_heart

Can't agree anymore. Only reason I went with vue is this class component. Didn't realize it will stop supporting such a major feature (Not sure we should even call this a feature but like a framework). Thank god that vue facing decorator has taken this up.

[dboris65]

Once upon a time, Internet Explorer 5 brought many new options in world of browsers. When Internet Explorer 6 appeared after it, it declared obsolete all the novelties of the previous version in order to introduce its new options and capabilities. And after it, Internet Explorer 7 was published, which declared deprecated all the solutions introduced in the previous two versions of IE in order to present its own new solutions and so on. Internet Explorer no longer exists today.

What I am about to say may seem harsh, but it is true. If you can't maintain some part of your project, don't even start it. Sudden changes in the development course of a framework cause suspicion among developers. If Vue 4 repeats a similar mistake, I fear it will end up like Internet Explorer.

For the future of this framework, it might be a good idea to consider returning support to this part of the project or to support the vue-facing-decorator project, but in such a way that it is not just a community-maintained project.

[WhatNot911]

Internet Explorer no longer exists today.

Boy oh boy oh boy
I just spent like an hour trying to make a table with a scrollable body for IE11 and XSLT, and I do that for money (as in a job)
Trust me it ain't trully gone especially in some government sectors

[dboris65]

Boy oh boy oh boy I just spent like an hour trying to make a table with a scrollable body for IE11 and XSLT, and I do that for money (as in a job) Trust me it ain't trully gone especially in some government sectors

Really? In that case, don't waste your time here.

[WhatNot911]

Boy oh boy oh boy I just spent like an hour trying to make a table with a scrollable body for IE11 and XSLT, and I do that for money (as in a job) Trust me it ain't trully gone especially in some government sectors

Really? In that case, don't waste your time here.

No u XD