How to update to decorator stage 3？

[ruojianll]

Decorator proposal is stage 3 now. In this stage, decorator must return a class value (not any value). In v-f-d, Component decorator returns vue option component( a plain JS object). Let's discuss how to update to stage 3 decorator proposal.

https://github.com/tc39/proposal-decorators

I don't suggest use vue internal __vccOpt api, because it is not stable and not documented, so there may should be a toOption method to convert decorated class to vue option component.

https://github.com/vuejs/core/blob/98f1934811d8c8774cd01d18fa36ea3ec68a0a54/packages/runtime-core/src/vnode.ts#L543

@Decorator
class MyComp extends Vue{}

export default toOption(MyComp)

[ruojianll]

@armano2

[armano2]

i don't understand why do we need toNative that should be done in decorator itself...

---

Decorators in essence are already wrappers with fancy syntax

export default Decorator(
  class MyComp extends Vue {}
)

[armano2]

just a small tip, instead of eagely releasing changes its a good practice to make PR's and ask ppl for feedback :)

its not a big deal for smaller repos, but bigger you become more important it is

[ruojianll]

@armano2 Because in stage 3, class decorator couldn't return a non-constructor value(a vue options component, also a plain js object) to instead the class itself. There is a gap between decorated class component and vue options component. So far, toNative is not necessary if user don't want to use it because vue internal api __vccOpts is still work.
I asked people in here but most of them don't care.

[rdhelms]

@ruojianll Since Vue core already has a defineComponent function for the Options API, maybe vue-facing-decorator could export a defineClassComponent function that receives the decorator's class value and does the final conversion into the necessary options API default export?

Something like

<script lang="ts">
    import { Component, defineClassComponent } from 'vue-facing-decorator'

    @Component
    class MyComponent extends Vue {}

    export default defineClassComponent(MyComponent)
</script>

Where defineClassComponent is something like

function defineClassComponent (ComponentClass) {
    const componentInstance = new ComponentClass()

    // Map any static and instance ComponentClass values to object for Options API
    const componentOptions = ...

    return defineComponent(componentOptions)
}

[ruojianll]

I released beta version to migrate to decorator stage 3. If you want to try, see https://facing-dev.github.io/vue-facing-decorator/#/en/next-version/next-version

[ruojianll]

For users, use defineComponent to define a component in native vue.

export default defineComponent({
    // define component details here
})

in v-f-d, defining a component is declaring a class

@Component //defining a class component
class Comp extends Vue{

}

export default toNative(Comp) //tranform(unbox) the component to vue native component

This is what users think about defining a component, in my opinion.

[rdhelms]

Yeah, I definitely can see what you mean. It would be great to get some more voices in here to weigh in...I can see it both ways. Personally defineClassComponent is still more intuitive to me, but I could see others seeing it differently, as you've said.

I'm having a hard time coming up with any third name option 🤔

[ruojianll]

Or .. toVanilla? Don't hurry, there is a long time to finally release v3. 😊

[rdhelms]

Another naming idea...what if:

1. we stopped wrapping buildComponent's return in defineComponent (so return defineComponent(option) would become return option)
2. vue-facing-decorator could then export its own defineComponent function (or we could go back to defineClassComponent if we want to stay separate from Vue's defineComponent), which could accept a VueCons type and use Vue's defineComponent in its return: return defineComponent(slot.cachedVueComponent)

That way, it can make it more clear that the "defining a component" step is still happening at the end, just like in normal Vue. The @Component decorator is a convenience for defining the component options, but the real "define" step (as Vue core uses the term) really is still happening at the end

[rdhelms]

@ruojianll Any more thoughts on naming re: above^ ?

I think for our own team anyway if 3.x sticks with toNative, we'll probably just alias it as defineClassComponent in our own app 🙂 That's what seems to make the most sense in our team

[rdhelms]

@ruojianll That's a good point about v-f-d needing to follow vue's decorator settings. I think you're right. So while vue stays with experimentalDecorators we should keep v3 in beta, but if vue removes experimentalDecorators then v-f-d v3 will be released?

[ruojianll]

v3 is compatible with stage3 and stage2 both. If v3 is stable enough, we could release it. It is also relative to other decorator libs. If users need to use stage3 libs, they need to use v-f-d v3.

[rdhelms]

Yeah, I guess you're right...I'm just not looking forward to having to go through all our components to add the extra line at the bottom and move the export default 😜

[ruojianll]

In fact, exporting your class component directly (without toNative) works too in 3.0.0-beta.3. Because Component decorator sets vue internal api __vccOpts, but if vue removes it in the future, there will be a crash. You could don't use toNative if you don't care the risk.

[rdhelms]

That's awesome - I didn't realize that exporting the class component directly would still work in v3 💯

[wangzhiguoengineer]

@yyx990803
Hello Evan, You are the author of Vue. Can you give some suggestions?

[rdhelms]

@wangzhiguoengineer Just FYI...I wouldn't suggest trying to pull the vue core team into vue-facing-decorator discussions...the current official stance from Vue is not to use class components at all, so I doubt that anyone there will want to devote time to supporting this package (yet).

I think we would really need to build community support for this package and for class components in general before lobbying for official support from the Vue team.

(Though if I'm wrong and if the vue team decides to start officially supporting class components via this package, that would be awesome 😀)

[ruojianll]

@yyx990803 The biggest risk is if __vccOpts will be stable in vue 3.

[ruojianll]

@rdhelms
Do you think it's time to merge 3.x into main version?

[rdhelms]

@ruojianll I just tested our app with 3.0.0-beta.3 and keeping experimentalDecorators: true and everything still seems to work great! The functionality seems ready to go as far as I can tell 👍

I think it would still be helpful to have some good release notes in order for everyone to know that you can still use 3.x with experimentalDecorators: true without breaking changes

[ruojianll]

@rdhelms Would you test it with experimentalDecorators: false in your project? It should be compatible well.

[rdhelms]

@ruojianll I'll take a look on Tuesday 👍

Just to clarify - do you mean with experimentalDecorators: false and with using toNative? Or did you somehow make it work to turn off experimental decorators without needing toNative?

[ruojianll]

@rdhelms toNative is a very simple function. So you could test v3 just on you code base, using toNative or not is not matter.

[rdhelms]

@ruojianll It seems like 3.0.0-beta.3 was working well in my project, although I tried to briefly test it with a fresh Vue 3 app using create-vue and I'm getting a Uncaught SyntaxError: Invalid or unexpected token error when experimentalDecorators is false. Are you able to take a look? Here's a branch with what I was testing:
https://github.com/rdhelms/vue3-migration-reference/tree/vfd-v3-testing

[kliehm]

In vue-property-decorator v10.rc3 or vue-class-decorator v8.rc1 they use @Options instead of @Component. Would this be an option?
With the current (not next) release of vue-facing-decorator, vue-test-utils throws an error "Class constructors cannot be invoked without 'new'" when I mount(MyComponent). Could this be related to the @Componentdecorator?

[ruojianll]

#54 (comment)