Vue 3.0 support

[avxkim]

Hi, do you plan to support this project when 3.0 arrives? Or the Vue core team would integrate classes API natively?

[kaorun343]

@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.

[kaorun343]

In my humble opinion, the new api, the composition api is much better than the class style syntax.

[GerardSmit]

Fyi, vue-class-component will support Vue 3. See https://github.com/vuejs/vue-class-component/issues/402#issuecomment-593134671 for more information.

[avxkim]

Yeah, they are going to support classes in 3.0, even make a bridge for composition API, what do you think @kaorun343

[haoqunjiang]

vue-class-component v8.0.0-alpha.2 has been released to support Vue 3. Any plans for this package to move along?

[haoqunjiang]

https://github.com/vuejs/vue-class-component/tree/next

[CharlieBrownCharacter]

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

[zischler]

@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.

[sunhao0313]

stay tuned @kaorun343

[Karnith]

Vue 3 released yesterday.

[BoBoooooo]

Looking forward to update !

[kosratdev]

@kaorun343 do you have any plan to support Vue.js 3?

[wtho]

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+

[John0King]

@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

[wtho]

@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:

[fluffynuts]

@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.

[Chris2011]

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 :)

[mirata]

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

[aliibrahimroshan]

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)

[sergeych]

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.

[fluffynuts]

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.

[sergeych]

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.

[Chris2011]

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.

[John0King]

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})

[softboy99]

vue-class-component hase released 8.0 rc1,when we can get this ready?

[kaorun343]

Please check this. https://www.npmjs.com/package/vue-property-decorator/v/10.0.0-rc.2

[SuspiciousLookingOwl]

Awesome! Just for clarification, @Model is supposed to replace @PropSync right?

[kaorun343]

@SuspiciousLookingOwl Yes, use Model decorator instead, please.

.sync is removed from Vue 3.

https://v3.vuejs.org/guide/migration/v-model.html#overview

[sergeych]

+1, awesome! Thanks!

On 6 Mar 2021, at 14:52, kaorun343 notifications@github.com 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.

[nicolidin]

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.

[kaorun343]

@nicolidin Thanks for your feedback. I've updated @Provide decorator and released v10.0.0-rc.3 . So, could you try the new version?

[nicolidin]

"@ nicolidin" you mean? So yes, I've just tried and it works perfectly!

Btw if we surround our property by reactive() it makes it reactive! So it's great!

[ssipak]

Hi @kaorun343, thank you so much for Vue 3 support! There is a weird issue I stumbled on while converting one quasar component library to the new version. I'm not sure whether I should write it here or open a new issue, so here it is. There's also a doubt that I did the inheritance thing right in the first place. At least it worked on previous version.

Let's say we've got a base component class Bird that is extended by two other components (say Duck.vue and Goose.vue).

// Bird.ts
export default class Bird extends Vue {}

// Duck.vue template
<div>{{ name }} {{ says }}</div>

// Duck.vue script
export default class Duck extends Bird {
@Prop({ default: 'duck' }) name!: string
}

// Goose.vue template
<div>{{ name }} {{ says }}</div>

// Goose.vue script
export default class Goose extends Bird {
@Prop({ default: 'honk' }) says!: string
}

// somewhere else
<duck/>
<goose/>

Everything seems to work as it's supposed to, the duck's name is 'duck', the goose says 'honk', Vue warns us, that the props 'name' and 'says' accordingly were accessed during rendering but weren't defined.

Then if we add a prop to the base class (say @Prop({ default: true }) isFlying!: boolen), both duck and goose somehow are rendered to

duck

and we get a message about the non-defined 'says' prop repeated twice.

And if it is converted to @Options({ props: ... }) syntax, it works as it should then. The issue shows up on 10.0.0-rc.3 version. Hope it'll help improving the library a bit. Many thanks again!

[kaorun343]

@ssipak

Could you try like this? It seems extends Bird causes this bug. Instead of extending Bird, using mixins solves this bug.

( Using @Options is not necessary. )

    @Options({ name: 'Bird' })
    class Bird extends Vue {
      name: string | undefined
      says: string | undefined

      @Prop({ default: true }) isFlying!: boolean

      render() {
        return h('div', null, `${this.name} ${this.says}`)
      }
    }

    @Options({ name: 'Duck' })
    class Duck extends mixins(Bird) {
      @Prop({ default: 'duck' }) name!: string
    }

    @Options({ name: 'Goose' })
    class Goose extends mixins(Bird) {
      @Prop({ default: 'hook' }) says!: string
    }

    @Options({ name: 'MyComponent' })
    class MyComponent extends Vue {
      render() {
        return h('div', null, [h(Duck), h(Goose)])
      }
    }

[ssipak]

Yay! It worked! Brilliant! Thank you! Now I wonder how it could work without mixins on older versions :)

[djpate]

Thanks. Works Great!

[tinobino]

Hi! It seems that there is a bug when running tests via vue-cli-service test:unit. I've created a repository for that: https://github.com/tinobino/vue3-class-sfc-test

When using the import for "Options" and "Vue" from "vue-property-decorator" sub components can't be resolved anymore. When I change the import to "vue-class-component" it is working as expected.

[kaorun343]

@tinobino I checked your repository, and I also ran into the same problem. I found that the Vue components decorated by the re-exported '@Options' decorator doesn't contain any child components in '$options.components'. However, I have no idea to solve this problem now.

[pedro-gilmora]

How is it going this request? Can we use vue-property-decorator in Vue-3? Is there out any github repo up-to-date?

[Chris2011]

Hey @pedro-gilmora what is missing for you? Last commit is from 19 days ago and if you follow this ticket it seems fixed so short answer is yes, it is working and it is up to date :)

[Chris2011]

@armenr hey, it would be good, if you have a little reproducible project, that you can share with us to help you :)

[Chris2011]

To be honest @armenr I don't think that this is the right place to discuss your problem. Please just use the discord chan for example: https://vue.land. This section here is for creating issues and feature requests. If you have a problem with migration in your example, you should discuss this with an other community.

[armenr]

@Chris2011 - no problem. I don't think I'll be using this, moving forward. I may revisit it at some later time, depending on whether a stable release is accepted, and/or when documentation becomes clearer. Thanks!

[Klowes]

@Chris2011 is this library stable in Vue 3 coming from a Vue 2 project outside of fixing the breaking changes going from Vue 2 => Vue 3?

[mayuxian]

In vue3.0, if you don't use @ provide, how to bind a private variable to reactive, because @ provide generates more provides

[Chris2011]

@armenr I think this package is stable to use. I mean if it is not stable it would be RC or Beta, right? Sure maybe it has some bugs and I didn't try it out yet, but I will do it soon to check it out.

@Klowes I'm not the author of it and I didn't test it yet, but I will use it for my next project, which is still in pipe and this is a project from the beginning so no migration. But this is just my opinion. I will try to use it, that's it.

[revidee]

@kaorun343

While using mixins(), @Prop() is working fine for me, but @Inject() from the parent component is not available for the extending sub component.

See the codesandbox for a minimal example: https://codesandbox.io/s/vue-property-decorator-inject-inheritance-270gb

[ghost]

the new "10-rc" works great like magic but im getting this error

Module '"vue-property-decorator"' has no exported member 'Component'.

should i not be using this @component syntax anymore?

Thank you @kaorun343 !!

[Chris2011]

@adnan-wahab afaik @component doesn't work anymore. In this ticket here you can see @Options. Didn't test it yet, but this is the replacement.

[John0King]

@kaorun343 @Chris2011 I think we can use

export function Option{}

export const Component = Option;

to back support the Vue2 source file.

I personally think that migrate Component to Option is just an intrigue from Vue team, because their's recommend syntax (eg. function like) has break change in source.

but we can make it better , so people migrate Vue2 to Vue3 using this library has less pain