a few suggestions from someone using Vue + TypeScript every day for the last six months about vue

[chiubaca]

@Roninii
I think there is a little bit of confusion between Class Components and the proposed(now abandoned) Class API. I'm still wrapping my head around all this but this is my current understanding of the whole situation.

Currently we have Vue class components - https://github.com/vuejs/vue-class-component . This is an officially maintained extension of Vue.

This is different from the Vue 3 Class API proposal - vuejs/rfcs#17 . Though very similar there are few subtle differences outlined in the RFC. This was in direct competition with the Composition API. As we now know, the Composition API won this battle. As linked above, this is Evan You's reasoning as to why it was dropped - vuejs/rfcs#17 (comment) .

However, there are no plans to deprecate the current Vue class component. In fact, there is an open issue to adapt the Vue class component for the upcoming changes for Vue 3 - vuejs/vue-class-component#406 .

Sorry I realise this is a bit a brain dump. Please correct me if I'm wrong anywhere.

I'm currently in the process of refactoring one of projects to use class components. So happy to start working on this section. I've been holding off because it seems to be a slightly polarising topic in Vue land. But in the context of using it for better Typescript support, I think it makes a lot of sense!

[Roninii]

I 100% agree that this should be supported and added to the cheat sheet.

My only concern is that I think the issue thread noting why the proposal was dropped, and what the drawbacks vs. the composition api are.

It will certainly always be an option for those that prefer to use it anyways, and I think that should be encouraged in something so expressive as code. I would just like to add a note that defineComponent is the preferred and official approach.

[IAMtheIAM]

I am in the process of refactoring an Options Vue 2 app into the class Component style. I was confused about Class Component and Class Api @chiubaca Thanks for clarifying the difference!

Personally, I prefer the class component syntax because it's formalized and mostly standard TypeScript. That allows for easier transitions between frameworks like Angular, Vue, React, etc.

The only thing I was wondering about is what the equivalent of setup() is from the Composition API but when usnig Class Components. But I figured it out. There was a note about not the constructor function to run initialization code for the component when using Class Components, so we can just run our initialization code in the early view lifecycle hooks such as created().

Awesome writeup @louisreingold!

To add to that

• Originally I was using Vuex for basic state management, but now I've dumped it and switched to Akita which is way more robust and easy to use when paired with TypeDI. Now you have easy dependency injection with reactive state management.

[chiubaca]

Nice tips! Will find a way to incorporate this all in. I'm encountering point number 4 too, know of any good patterns to workaround this?

[swyxio]

awesome tips louisreingold !

[Roninii]

Awesome advice! If you've got the time for a PR, it's more than welcome! Otherwise we'll get to it soon (:

As for point 1, I definitely think it should be noted that Vue 3 is moving away from this set up as shown here and here, and I personally wouldn't encourage anyone to use this approach.

Of course these are just my opinions and a section demonstrating this approach could still be included as an option!