You can use property accessors to declare computed properties. See Vue Class Component. The getter will be triggered as soon as you type in the input.
For example:
<template>
<div>
<input type="text" name="Test Value" id="" v-model="text">
<label>{{label}}</label>
</div>
</template>
<script lang="ts">
import { Component, Vue, Watch } from "vue-property-decorator";
@Component({})
export default class About extends Vue {
private text = "test";
get label() {
return this.text;
}
}
</script>
Update for Vue Composition Api
<template>
<div>
<input type="text" name="Test Value" id v-model="text" />
<label>{{label}}</label>
</div>
</template>
<script lang="ts">
import { defineComponent, ref, computed } from "@vue/composition-api";
export default defineComponent({
setup() {
const text = ref("test");
const label = computed(() => {
return text.value;
});
return {
text,
label
};
}
});
</script>
You can use property accessors to declare computed properties. See Vue Class Component. The getter will be triggered as soon as you type in the input.
For example:
<template>
<div>
<input type="text" name="Test Value" id="" v-model="text">
<label>{{label}}</label>
</div>
</template>
<script lang="ts">
import { Component, Vue, Watch } from "vue-property-decorator";
@Component({})
export default class About extends Vue {
private text = "test";
get label() {
return this.text;
}
}
</script>
Update for Vue Composition Api
<template>
<div>
<input type="text" name="Test Value" id v-model="text" />
<label>{{label}}</label>
</div>
</template>
<script lang="ts">
import { defineComponent, ref, computed } from "@vue/composition-api";
export default defineComponent({
setup() {
const text = ref("test");
const label = computed(() => {
return text.value;
});
return {
text,
label
};
}
});
</script>
Because of the circular nature of Vue’s declaration files, TypeScript may have difficulties inferring the types of certain methods. For this reason, you may need to annotate the return type on methods like render and those in computed.
import Vue, { VNode } from 'vue'
const Component = Vue.extend({
data () {
return {
msg: 'Hello'
}
},
methods: {
// need annotation due to `this` in return type
greet (): string {
return this.msg + ' world'
}
},
computed: {
// need annotation
greeting(): string {
return this.greet() + '!'
}
},
// `createElement` is inferred, but `render` needs return type
render (createElement): VNode {
return createElement('div', this.greeting)
}
})
If you find type inference or member completion isn’t working, annotating certain methods may help address these problems. Using the --noImplicitAny option will help find many of these unannotated methods.
More Info
What is vue-property-decorator?
Is vue-property-decorator popular?
Is vue-property-decorator safe to use?
» npm install vue-property-decorator
TL:DR
I'm new in Vue (coming from React) but from what I understand the answer above is not wrong but it doesn't answer the question of how to use @Model decorator. Provide and Inject is an overkill for passing props from parent to child. The documentation is not clear, so I scratched my head a lot on this one. But remember that the package is referring to props. Hence @Prop, @PropSync and @Model should be at the child component. Here is what I did and it didn't throw out that horrible console error. Parent component:
<template>
<div>
<input type="text" v-model="modelText" />
<Child
:modelText="modelText"
/>
</div>
</template>
<script lang="ts">
import Component from 'vue-class-component';
import Vue from 'vue';
import Child from './Child.vue';
@Component({
components: {
Child,
}
})
export default class Parent extends Vue {
private modelText: string = 'model-text';
}
</script>
And for the child component:
<template>
<div>
@Model: {{modelText}}
</div>
</template>
<script lang="ts">
import Vue from 'vue';
import Component from 'vue-class-component';
import { Prop, PropSync, Model } from 'vue-property-decorator';
@Component({
})
export default class Child extends Vue {
@Model('input', { type: String }) modelText!: string;
}
</script>
Since v. 9.1.2 view-property-decorator now supports the @VModel decorator.
Where
import { Vue, Component, VModel } from 'vue-property-decorator'
@Component
export default class CustomComponent extends Vue {
@VModel() name!: string
}
will make it possible to use two-way-databinding with name inside the component and v-model="..." from the outside. Without the annoying warnings!
https://github.com/kaorun343/vue-property-decorator#-vmodelpropsargs-propoptions-decorator
We are using Vue 2 with a lot of components built on top of class based components using vue-class-component and vue-property-decorator.
Now we need to upgrade to Vue 3 for better performance and long time support.
To answer your questions:
I did a lot of research and there is no plan to support class based components going forward from here. The two plugins from above are stuck at RC level for Vue 3. See: https://github.com/vuejs/vue-class-component/issues/406
A library which is not maintained and/or properly tested with a new Version of Vue is never a good idea to use imo.
Thats a question where there is no clear answer for.
You can try this strategy, maybe it works for you too:
We added the composition API and script setup via these plugins to our existing Vue 2 code base:
- https://github.com/vuejs/composition-api
- https://github.com/antfu/unplugin-vue2-script-setup
Update 22/07/10: Vue 2.7 (the last minor release) was released, there is no need for the plugins above when using this version: https://blog.vuejs.org/posts/vue-2-7-naruto.html
This allows us to use composition API + script setup and class based components simultaneously. So we are beginning to write new components with the new syntax and rewriting old code step by step. When we are done with this process, we are going to migrate to Vue 3 using the migration guide:
- https://v3-migration.vuejs.org/
That is a lot of work and very annoying to do, as it takes a lot of time away from new features or bugfixes which are more important than dealing with this upgrade pain. But we hope going forward from here that Vue is going to me more stable in their decisions and how they want to continue forward.
I also agree with you saying that class based components are a more elegant way to do things than the composition API. It is also shorter and closer to backend programming languages. Its very sad to see this one go.
All the best Jakob
Update 23/04/14: Great new article on how one could continue using class based components: https://medium.com/@robert.helms1/vue-2-to-vue-3-with-class-components-cdd6530a2b2a
Further ressources:
Guide: https://levelup.gitconnected.com/from-vue-class-component-to-composition-api-ef3c3dd5fdda
More reasons why they drop it:
https://github.com/vuejs/rfcs/pull/17#issuecomment-494242121
https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md#type-issues-with-class-api
https://vuejs.org/guide/extras/composition-api-faq.html#better-type-inference
FWIW, despite the fact that I am really more a fan of using class based components, we made the decision to convert all our ±300 components to Options API. So at least we can upgrade to Vue@3 and Vite.
Changing the complete codebase to Composition API (with <script setup>) is not worth it and potentially error prone. All new components will be written with <script setup> though.
Steps that we followed to get there:
- Make sure you are at [email protected]. This version includes backported features from vue@3, including Composition API and
<script setup>. See their blog. - Check and update all dependencies to be compatible with [email protected] (e.g. we make extensive use of AgGrid that needed to be at version 27).
- Gradually convert all class components to Options API via this package: https://www.npmjs.com/package/vue-declassify. (Only the
@Emitdecorator needs to be handled manually).cdinto a directory that you want to convert and run this command:find . -name "*.vue" -exec vue-declassify {} \;to execute the converted on multiple vue files sequentially.
This process took us approximately 2 days to execute completely.
NB: Make sure that your codebase is thoroughly backed by unit and e2e tests prior starting this process .