vue-property-decorator
vue-property-decorator copied to clipboard
kaorun343
Vue 3.0 support
Hi, do you plan to support this project when 3.0 arrives? Or the Vue core team would integrate classes API natively?
@webcoderkz
Hi.
This library depends on vue-class-component. If vue-class-component supports v3.0 and it provides an API for third party libraries including vue-property-decorator, I will continue maintaining this library.
In my humble opinion, the new api, the composition api is much better than the class style syntax.
Fyi, vue-class-component will support Vue 3. See https://github.com/vuejs/vue-class-component/issues/402#issuecomment-593134671 for more information.
Yeah, they are going to support classes in 3.0, even make a bridge for composition API, what do you think @kaorun343
vue-class-component v8.0.0-alpha.2 has been released to support Vue 3. Any plans for this package to move along?
Any news on this? If you wouldn't support Vue 3 some people would have to switch to other class based component alternative. Could you let us know, please
@kaorun343 any updates? I'm currently starting to migrate everything to the newest Vue 3 beta in my boilerplate, which I use for all my projects.
For everyone interested, the Prop decorator will probably go away, as heavily discussed currently in vue-class-component repo (see Link below).
As explained in some of these issues, the decorator has to go away to enable type completion for props inside templates of other components using TSX, which I think is an awesome feature.
WebStorm already provided this, but in an own fashion, not using TS language servers or open source plugins. Soon we all will be able to leverage this feature, but only if we give up on our loved Prop() decorator.
I personally think I can get used to a different Syntax. Anyway I just wanted to point you guys there, as now is the time participate in the discussion.
On the other hand, if you really would not like to give up on Prop() at all, I am sure there can be a third-party library like vue-property-decorator which still offers this functionality, but this will prevent property completion in templates.
Have a look at all v8 issues and read carefully through them before jumping into the discussion, plus, be nice to ktsn, the maintainer of vue-class-component:
https://github.com/vuejs/vue-class-component/issues?q=is%3Aissue+label%3Av8+-label%3Abug+
@wtho https://github.com/vuejs/vetur/pull/1323 I don't think so, vue-property-decorator is now be supported in vs code for intellsence
@John0King oh, sorry about the confusion, my post was only regarding Vue version 3 (vue-class-component version 8), as this issue is as well about Vue version 3.
Vue Version 2 will always work with Prop decorators and does have some VS Code Intellisense support included in Vetur :+1:
@wtho please see https://github.com/vuejs/vue-class-component/issues/465#issuecomment-711105270 which suggests that @Prop should probably not go away.
Personally, I don't care about TSX -- and I think there's probably other people out there with the same viewpoint -- so whether or not @Prop provides typings for TSX really doesn't matter to me. Property completion within templates in WebStorm work just fine too -- whilst I'm happy for people not using WebStorm to get extra support, I'm also quite happy to just keep on the way I am.
I imagine that there are a reasonable number of people who are simply comfortable with the class support that vue-class-component and vue-property-decorator provided in vue2, and would like to upgrade projects to vue3 to take advantage of newer patterns in work going forward (or not: Evan You has been quite vocal about the composition api not deprecating the class api) and / or performance enhancements that have come across the board in vue3. I'm sure there are a bunch of people who would be very grateful for continued support.
Right now, I have to decide between opening an issue for warnings against vue-property-decorator and vue3 (re-exports of default exports from vue-class-component and vue which no longer exist) and changing up how my team has worked for about 2 years now, successfully.
Thx @fluffynuts I also don't care about TSX and just adding features for one specific thing is not very well IMHO. So maybe it should have both options. One for TSX what will not be the @Prop and the default way with @Prop. I think it is a narrow ridge between making both happy or just one side. But I'm with you :)
I also have the situation where we have a Vue 2 project built extensively with vue-property-decorator. Whatever the vue 3 solution is, I would hope that there is a clear migration path so that changes and regression testing can be kept to a minimum, or at very least - made predictable and quantifiable
vue-property-decorator is not working with vue 3 and typescript . When doing extends vue it says Type 'typeof import("c:/Myserver/htdocs/vue/node_modules/vue/dist/vue")' is not a constructor function type.Vetur(2507)
I hate "new" syntax of vue 3 concerning properties and calculated properties. Sone ecge epoch before classes and decorators were introduced... Please give us back our @Props and calculated values as getters/setters, methods or we'll get back to react... it is same ugly as vue 3 but has react native to sweet the pill.
vue has vue native (https://vue-native.io/), so there's no real win with react native, imo
personally, I'm almost at the point of working out an upgrade-in-place alternative to this library - for us to upgrade is no minor feat, and I guess it's not that easy for anyone else either. I can deal with the stuff that we need to change to support vue 3 (like no event-bus usages), but not having the decorators that we had before is literally the only reason we aren't embarking on a vue3 upgrade at the moment.
Thanks, I like it.
Same here, Just yesterday I refused to start new project in vue3 as we have too mach code and experience with decorators. Will use again good old v2.
vue has vue native (https://vue-native.io/), so there's no real win with react native, imo
personally, I'm almost at the point of working out an upgrade-in-place alternative to this library - for us to upgrade is no minor feat, and I guess it's not that easy for anyone else either. I can deal with the stuff that we need to change to support vue 3 (like no event-bus usages), but not having the decorators that we had before is literally the only reason we aren't embarking on a vue3 upgrade at the moment.
vue-native is just a wrapper around the APIs of React Native. So no real alternative. But to be honest, I've never tried it.
I have a thought that is build an VueTs with VueJs 3.0 source code, vue is using javascript as a configuration file, and my thought is about direct using class to configure the Vue instance.
「 <= Object Configuraion factory <= object
Vue <= ComposeFactory <=|
L <= class Configuraion factory <= class
with this structure we get rid of the vue object limitation , get all benefit that class have.
also add support Service to replace mixins, and current mixins can be use with MinxenService({ mixins})
Please check this. https://www.npmjs.com/package/vue-property-decorator/v/10.0.0-rc.2
Awesome! Just for clarification, @Model is supposed to replace @PropSync right?
@SuspiciousLookingOwl Yes, use Model decorator instead, please.
.sync is removed from Vue 3.
https://v3.vuejs.org/guide/migration/v-model.html#overview
+1, awesome! Thanks!
On 6 Mar 2021, at 14:52, kaorun343 [email protected] wrote:
Please check this. https://www.npmjs.com/package/vue-property-decorator/v/10.0.0-rc.1 https://www.npmjs.com/package/vue-property-decorator/v/10.0.0-rc.1 — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kaorun343/vue-property-decorator/issues/294#issuecomment-791949206, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACJIIMXWVI7LRTCKQ5CNMTTCIXSFANCNFSM4KCZ4GJA.
Hi, thanks a lot @kaorun343 for this vue3 support!!
However, I just tried the@Provide decorator and it is by default reactive. It means if the parent component modifies the provided value, the child will get the updated value too. Whereas when the native provide is used in the @Option decorator we can see it is non-reactive, so there is a mismatched with the vue API.
