vue-class-component
vue-class-component copied to clipboard
vuejs
[vue3] When is 8.0 releasing?
It looks like v8 rc was released a long time ago. When is the final version expected?
I was wondering the same thing. The next branch looks pretty dead to me, please prove me wrong!
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?
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
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.
Side note which might help pushing this, Vue 3 is now default aka Vue 3 is now released has of Feb 7 🚀
@ktsn This feature is very important to me. Do you have any progress or update?
I'm looking for status update of v8 and wondering about it's long term viability. Can anyone provide some insight?
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.
@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.
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
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.
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.
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.
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?
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
My two cents after a few months: Composition API has completely replaced vue-class-component for me. Try it out.
My two cents after a few months: Composition API has completely replaced
vue-class-componentfor me. Try it out.
The problem is that with a huge codebase there is no migration strategy between vue-class-component and composition api. It's a tough decision to rewrite everything to composition API without knowing if they decide to abondon that in the future again out of some reason or rather use a more "developer/large codebase friendly" solution like Angular where a migration to a new version is automated as good as possible.
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.
I had picked Vuejs for it's simplicity and closer relation to AngularJS after getting burned by AngularJS being effectively dropped. Now I'm twice burned. I've read quite a bit about the composition API, and I can't see anything that demonstrates it's superior architecture. Sure the make claims left and right about how awesome, but nothing I've read convinces me it's any better than class-based. There is a significant amount of boiler plate code composition API creates that didn't exist with class-based API. It's only "better" as a matter of taste not an objective truth.
My two cents after a few months: Composition API has completely replaced
vue-class-componentfor me. Try it out.
I mean you can see that the people crying over here are Leeds having to migrate everything they worked on for 4 years into a completely new framework and workflow and standards and dev tools and libs. By the time you are done with all of this if you are an SME may god be with you while looking at a recession and cost cuts. If you are a smaller org GG WP better luck next time. If you were an agency say bye to all the clients you recommended this to when you ask them for budget increases to mitigate to prevent catastrophic failure via deprecation. I don't think you understand the severity of this entire fiasco. Im flabbergasted that more YouTubers and influencers aren't talking about this. Its the nitty gritty stuff that might not get all the views but damn I wish I had the platform to prevent someone just like me who 3 years back saw vue2 as a great option to not fall into the same pitfall again with Vue3.
The maintainers have forgotten that what makes or breaks a framework is adoption. Its people. Angular had to fight its way out of that mess and still people are sceptical about it because of the js to angular 2 fiasco. Its ratings are low and adoption is low due to the same reason.
What do you think will happen when people understand how flaky the community is. You mean to tell me no one in the core team can see this thread ? Why isn't there a formal response ? at least Nuxt is working on bridge. but that too for how long when its basis is Vue and SME's and Enterprise starts fleeing from it. when startups with good CTO's and leads start avoiding it.
They made promises that this will be maintained. what happen to all of that absolute garbage RFC promises.
I also hate how we aren't solutions oriented in this problem.
@jaeming if you guys want to do a fork(Idk how successful this would be as my personal intentions aren't to divide what's already so divided) or another alternative let's open discourse for that. Id just like to drive the point that we don't care how amazing the new system is if there's no easy and proper migration path. that's my two cents.
and if someone would like to colab on one I'm all ears and ready to help in any way shape or form.
I apologies for the heated comment but I hope you all understand where its coming from. I've tried pinging them on twitter. I've tried the thread on github. I don't really know what else I can do.
I've considered forking Vue 3, porting some of the nice to haves from Vue 2 that 3 removed, and having class based be a first class citizen.
The problem, of course, is finding the time, and yet another framework just fragments an already small user base, so getting support is optimistic.
The argument from Vue was that they didn't want to support 3 different ways to do the "same thing": Options, Composition, Classes which is the only substantive argument put forth from reading what little was said about it. The FAQ doesn't even try to give an argument and just unceremoniously denounces it without any justification. Quite telling about the attitude on the team towards this idea. However, as pointed out in this thoughtful post:
https://github.com/vuejs/rfcs/discussions/276
There wouldn't need to be large ceremony to give 1st class sanctioning of a different paradigm. It's mostly just recognizing it is a way of working with Vue and providing docs. However, when this is raised it's met with dismissive resistance and "Yeah but" arguments which shows that the community isn't open to this idea no matter its merits. So if this is a hill you gotta die on you'll have to reconstruct a new hill, pick up the pieces, and recreates typescript class support in a new project. I thought of the same thing, but then again who has the time?
The argument from Vue was that they didn't want to support 3 different ways to do the "same thing": Options, Composition, Classes which is the only substantive argument put forth from reading what little was said about it. The FAQ doesn't even try to give an argument and just unceremoniously denounces it without any justification. Quite telling about the attitude on the team towards this idea. However, as pointed out in this thoughtful post:
There wouldn't need to be large ceremony to give 1st class sanctioning of a different paradigm. It's mostly just recognizing it is a way of working with Vue and providing docs. However, when this is raised it's met with dismissive resistance and "Yeah but" arguments which shows that the community isn't open to this idea no matter its merits. So if this is a hill you gotta die on you'll have to reconstruct a new hill, pick up the pieces, and recreates typescript class support in a new project. I thought of the same thing, but then again who has the time?
That's wild considering they don't really want people using options over composition, so it seems to me they should have deprecated options instead and kept class-based for the 2 systems with first class support.
My two cents after a few months: Composition API has completely replaced
vue-class-componentfor me. Try it out.I mean you can see that the people crying over here are Leeds having to migrate everything they worked on for 4 years into a completely new framework and workflow and standards and dev tools and libs. By the time you are done with all of this if you are an SME may god be with you while looking at a recession and cost cuts. If you are a smaller org GG WP better luck next time. If you were an agency say bye to all the clients you recommended this to when you ask them for budget increases to mitigate to prevent catastrophic failure via deprecation. I don't think you understand the severity of this entire fiasco. Im flabbergasted that more YouTubers and influencers aren't talking about this. Its the nitty gritty stuff that might not get all the views but damn I wish I had the platform to prevent someone just like me who 3 years back saw vue2 as a great option to not fall into the same pitfall again with Vue3.
The maintainers have forgotten that what makes or breaks a framework is adoption. Its people. Angular had to fight its way out of that mess and still people are sceptical about it because of the js to angular 2 fiasco. Its ratings are low and adoption is low due to the same reason.
What do you think will happen when people understand how flaky the community is. You mean to tell me no one in the core team can see this thread ? Why isn't there a formal response ? at least Nuxt is working on bridge. but that too for how long when its basis is Vue and SME's and Enterprise starts fleeing from it. when startups with good CTO's and leads start avoiding it.
They made promises that this will be maintained. what happen to all of that absolute garbage RFC promises.
I totally understand your frustration and I'd love to hear an official statement on this yet here we are. As a side note it was quite tedious for me to rewrite everything to Composition API and I wish we had at least a migration strategy. I tried to address those who had opposed Composition API or was afraid of poor TS support.
It's probably not worth discussing anymore here unless one of us wants to fork or propose to maintainers someone who is willing to take over. For those looking to migrate, something as naive as this will work in some simple cases:
although you will probably want to go ahead and do a full refactor to avoid a bunch of issues:
I know a lot of people would say this is not that big of a refactor...but when you have a huge project (14,000+ commits, with 40+ devs contributing), that's a lot of re-training, refactoring, and QA regression testing you have to justify and then explain to management why you should continue on the Vue path when everyone else in the industry is telling them to React or Angular are the goto solutions.
If this project was finished and released it wouldn't really matter what Vue team did or said. There would be a viable project supporting class based Vue 3. This project was being worked on then abruptly stopped, but every time people asked about class based support in Vue 3 they said it was "Done", but the documentation just needed to be written. Then it never got written so is all that is left to make this work is write the docs? If not what else has to be done to release the next branch?
@chubbard Agree. In my opinion, the document should be written in class based components instead of current version. Class based components, decorators, jsx and TypeScript are important for modern javascript codes to build a large complex project. The document has been written in an embarrassed way.
@jaeming <script setup> is more magical and only used by vue. Vue single file component is also magical. Decorator pattern has been common used by many program languages as @ syntax, class or function. So in vue2 I use this repo with typescript, tsx and class based component. And divide them in to 3 files(class, render function, css) to build my component and import them. SFC is not easy to be maintained in a large component.