Deprecate vue-class-component

[Mikilll94]

Here you can read a post from Evan You @yyx990803 https://github.com/vuejs/vue-next/issues/4744#issuecomment-937369062

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 vuejs/vue-class-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: https://github.com/vuejs/vue-class-component/issues/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.

[rootux]

thanks. I've opened an issue on the repo to keep it clean here