-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vue3] When is 8.0 releasing? #584
Comments
I was wondering the same thing. The |
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: |
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? |
@ktsn Why not provide Vue constructor like before? |
any replies ? |
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. |
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 |
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) 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. |
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 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 <script setup> syntax which does exactly what a decorator on a class did and transforms the data in an object. <script setup> is not part of js either. It's also magical. That is sort of a double standard there. But whatever. As front-end Architect for my company I'll be proposing the next framework of choice for our micro-frontend architecture and it will not be Vue 3. |
My two cents after a few months: Composition API has completely replaced |
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. |
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. |
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. 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: 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. |
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. |
First release. |
This work is very important for VUE 3. and me |
I created a repository to solve this problem, As an alternative to vue-class-component, we will use it in large-scale projects |
So, I am in the process of migrating 3 large code bases to vue 3 is there a good solution to support class-based-components in Vue 3? At least for the time, I am rewriting every component. |
My old setup with SystemJS (as a bundler) support, without SFC and with ts-jest. I belong to that group of developers who don't like React style, where css imported in *.js but forced to import html template as String with config js-file. |
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/ |
I'm using this setup for vue3 - vue-class-component |
We decided that it is too much of an effort and are currently in the process of throwing vue out. Our managers do not feel comfortable proceeding with vue, if this is the behavior of the vue team once they switch their opinion. I know this lib was not "official", but it was officially recommended and Even You's account had much impact on this lib. So it feels really awful that it just got abandoned. |
We also made the decision to leave Vue. It's kind of funny that they garnered so much market share from angular.js users who were disenchanted with the changes and upgrade path to angular 2+ and now they follow in their footsteps by making the same mistake. |
We just completed migrating a 300+ components project from Vue 2 to Vue 3 with the help of vue-facing-decorator. There are a few minor glitches that need to be tweaked, but it's not a big deal. I highly recommend vue-facing-decorator for all of us who are tackling the migration to Vue 3. Thanks to the work of @ruojianll. |
@ingram90 |
@nseb We're also in the process of migrating several apps with 100+ components to Vue 3 using vue-facing-decorator, and so far almost all of the work has been from the official list of Vue 3 breaking changes, which would be issues no matter how you migrate the components themselves. The component "migration" was just doing a global find-and-replace of vue-property-decorator or vue-class-component with vue-facing-decorator. |
Also, vue-facing-decorator is officially linked as a suggested package in the vue-class-component readme and docs now, for anyone who hadn't seen that. |
@rdhelms Id love to get to know more about that journey, a blog when you have time maybe ? |
@rdhelms |
Most of our issues may be related to vue-facing-decorator, but I am not sure:
This does not work with facing decorator, but I don't think anyone writes it this way :)
|
@ingram90 @nseb We also changed our |
@rdhelms thx HomeLayout extends mixins(UMBaseComponent, AuthComponent) { in vue facing decorator it seems to be on the market, but my IDE (IntellijIdea) does not see the methods inherited from AuthComponent and puts me in error , I did not have the problem with vue-class-component |
@nseb I add new feature, which is similar to vue-class-component's mixins function to extends multiple components and keep type details . |
Has anyone used it with nuxt 3 ? |
@ruojianll @options({ |
@nseb You should do something to migrate. |
@ruojianll My faith in the community is slowly being restored thanks to you |
@BuddhiAbeyratne There's a new vue-facing-decorator beta version that @ruojianll just released which targets support for stage 3 decorators - it would be great for everyone thinking of using v-f-d to provide feedback there. And @ruojianll has been very responsive in issues and discussions there, as well as in the v-f-d discord server. |
@BuddhiAbeyratne |
Hello everyone, I've created a brand-new vue-class-component for Vue 3. It's implemented in pure JavaScript, eliminating the need for TypeScript configuration. Additionally, it incorporates the most recent (as of May 2023) stage 3 proposal of JavaScript decorators and stage 3 proposal of JavaScript decorator metadata. You can find it here: vue3-class-component We welcome feedback, bug reports, and contributions. Feel free to get involved! |
What's is the difference with vue-facind-decorator?
Le sam. 7 oct. 2023 à 19:04, Haixing Hu ***@***.***> a écrit :
… Hello everyone,
I've created a brand-new vue-class-component for Vue 3. It's implemented
in pure JavaScript, eliminating the need for TypeScript configuration.
Additionally, it incorporates the most recent (as of May 2023) stage 3
proposal of JavaScript decorators
<https://github.com/tc39/proposal-decorators> and stage 3 proposal of
JavaScript decorator metadata
<https://github.com/tc39/proposal-decorator-metadata>.
You can find it here: vue3-class-component
<https://github.com/Haixing-Hu/vue3-class-component>
We welcome feedback, bug reports, and contributions. Feel free to get
involved!
—
Reply to this email directly, view it on GitHub
<#584 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQRQWRLDFXP7SDFLAPJMLDX6GDR3AVCNFSM5LWKMEDKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZVGE3TOMJTG4ZQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hello everyone, I have created a vue3 framework with ioc container, named as You can find it here: https://github.com/cabloy/cabloy-front Do you agree with such a concept: Class should not be used in the Therefore, it is completely different from Cabloy-Front has a very important feature: With the support of ioc container, defining reactive states no longer needs Demonstration: no
|
It looks like v8 rc was released a long time ago. When is the final version expected?
The text was updated successfully, but these errors were encountered: