vuejs / vue-class-component

ES / TypeScript decorator for class-style Vue components.
MIT License
5.81k stars 429 forks source link

[vue3] When is 8.0 releasing? #584

Open ninjabhishek opened 2 years ago

ninjabhishek commented 2 years ago

It looks like v8 rc was released a long time ago. When is the final version expected?

Fleeck commented 2 years ago

I was wondering the same thing. The next branch looks pretty dead to me, please prove me wrong!

ninjabhishek commented 2 years ago

Agreed. Vue 3 typescript class based project works with 8.0, and working on rc candidate is a security concern in a corporate environment. @ktsn your views?

ruojianll commented 2 years ago

This work is very important for VUE 3.

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

jaeming commented 2 years ago

Agree as well. This is the major blocker for my team in updating a very large codebase to Vue 3. I remember hearing assurances from Vue core devs that the class syntax would not be abandoned in favor of composition api but I'm starting to wonder if this is the case anymore.

ghiscoding commented 2 years ago

Side note which might help pushing this, Vue 3 is now default aka Vue 3 is now released has of Feb 7 🚀

donggyu04 commented 2 years ago

@ktsn This feature is very important to me. Do you have any progress or update?

andyfu6 commented 2 years ago

@ktsn Why not provide Vue constructor like before?

nseb commented 2 years ago

any replies ?

pkzOR commented 2 years ago

I'm looking for status update of v8 and wondering about it's long term viability. Can anyone provide some insight?

pkzOR commented 2 years ago

I'm looking for status update of v8 and wondering about it's long term viability. Can anyone provide some insight?

To answer my own question, it appears that Vue no longer recommends class-components (https://vuejs.org/guide/extras/composition-api-faq.html#relationship-with-class-api) and so there is little incentive to maintain this.

nseb commented 2 years ago

@pkzOR , Thanks , I just read. About me , I hate the composition setup that I find it makes maintenance difficult because the code is unreadable. I come from the Java world, I use TS and VueClassComponent on a big project, I find the top balance between ease of development and maintenance.

ninjabhishek commented 2 years ago

Vue 3 ecosystem is messed up right now. The core libraries published by vue is interdependent, and so if one is not released, the others, even if released carry unsecured versions. One example would be https://github.com/vuejs/test-utils/blob/main/package.json where it is an rc version carrying the rc of vue-class-components. And then vue-cli-jest v5 carries v27-rc of vue jest. Vue 3 is not ready for enterprise yet. One scan, and we are under red alert

ImBoop commented 2 years ago

I'm looking for status update of v8 and wondering about it's long term viability. Can anyone provide some insight?

To answer my own question, it appears that Vue no longer recommends class-components (https://vuejs.org/guide/extras/composition-api-faq.html#relationship-with-class-api) and so there is little incentive to maintain this.

That's actually nuts. Their reasoning isn't sound at all, class API is more in line with the direction the web is moving, and is also far easier for developers to use. Angular, Web Components, and even React have first class (no pun intended) support for class based components. Vue randomly deprecating/removing features and having no sound strategy make it hard to justify using it in the future.

WolfspiritM commented 2 years ago

That's actually nuts. Their reasoning isn't sound at all, class API is more in line with the direction the web is moving, and is also far easier for developers to use. Angular, Web Components, and even React have first class (no pun intended) support for class based components. Vue randomly deprecating/removing features and having no sound strategy make it hard to justify using it in the future.

Yep. We also moved away from Vue to Angular and are currently rebuilding our components in Angular cause of that. It's sad but I also don't recommend using Vue anymore cause of decisions like that.

BuddhiAbeyratneAL commented 2 years ago

Im kinda ashamed to say this but as a TL this was a rookie mistake trusting in a org this young. We'll be moving to angular too for our new projects (hate my gut for this as I love class based vue and Vuex combo that Nuxt provided) it feels like the lac of good videos / docs and articles that was pushing for OOP standards made the path a not so well trodden one making it easier for replacement.

I still have a bit of hope that they will go to the http://typescript.nuxtjs.org/cookbook/components page and click the three options and see what's more readable and at least put some maintenance into it.

In the meantime our org decided to take our chances with going for micro front ends. we'll be breaking what we have and freezing some parts of the application and will move into other frameworks for the time being.

If any of you have code mods or migrations paths please let me know. Thinking of starting a codemod repo to do this.

PavelTurk commented 2 years ago

The same problem. I read about Vue and liked it for its simplicity. However, as a professional developer I use only OOP. I started a project with Vue3 having great hopes on vue-class-component. However, no documentation for v. 8, project hasn't been updated for a long time, no any answer from @ktsn . Unfortunately to start something serious in such conditions is too risky. So, goodbye, Vue and hello, Angular.

PS. No, really, it is 21'st century. Why wasn't Vue3 developed using OOP?

jaeming commented 2 years ago

This code-base is simple enough that probably anyone of us could fork it and maintain. The component decorator basically just transforms the class into Vue object syntax. I've implemented it from scratch as an exercise/poc. The problem is really the mentality of Vue core team, who suffered a lot of fallout from RFC when they dropped class syntax and went to composition API. A lot of toxicity was injected into discussions around the RFC and now class/decorator methodology is associated with that unfortunately. Therefore, it doesn't make much sense to support class/decorator based components when the Vue Core team is aligned against it or as Evan put it: it's definitely not recommended by Vue documentation any longer. Even with an actively supported library for this, I only see the demand for this syntax falling. It won't be recommended by Vue core team in any case. It's just a matter of time before it gets removed from Vue CLI probably.

Speaking of Vue CLI, Evan also commented that it would at some point soon enter maintenance-only mode, with preference given to Vite. So there is a migration you might want to plan as well if you have a large Vue app.

Personally, I'm feeling a bit burned. I was an early adopter of Vue since the pre 1.0 days. I got a startup that has since entered hyper-growth on it as our SPA of choice. We followed the best-typescript support path being recommended at the time (Vue-class-component). We used Vue CLI and Vuex. Now as well as changing out all our class component syntax and migrating to Vue 3 (with very little ROI) we also need to start planning migration from Vuex to Pinia and CLI migration to Vite.

It's funny because Vue gained a lot of popularity due to the AngularJS to Angular 2 era was even dubbed by a lot of fans as the "real" angular 2. Now it seems to be making the same mistakes. They don't care about their enterprise consumers I guess. I'm sure by now they've realized that by alienating so many of their consumers, it's going to slow their momentum. The Vue Eco-system is very confused. The core team is more reticent than previously. When I voiced concerns on the RFC I was invited to leave to whatever framework alternative I preferred right off the bat.

I'm not going to invest anymore time into a framework who's core team is willing to abandon core libraries with such disregard. The thing that burns me the most is that I heard Evan say he was against decorators because they were not yet part of JS and they were too magical. Meanwhile he introduces the Githubissues.

  • Githubissues is a development platform for aggregating issues.