ktsn
commented
6 years ago Disclaimer: I'm not familiar with the latest decorator spec yet and vue-class-component still use stage 1 decorator, so the following may not be applicable on the current spec.
TL;DR
It would be great for vue-class-component and vue-property-decorators if ES decorator does not initialize (overwrite) foo by undefined in the following case.
@Component
class MyComp extends Vue {
@Prop foo;
}The major difference between ES (babel legacy decorator) and TS decorators (--experimentalDecorators) is the behavior of class property initialization when there is no initializer. for example:
// Define Vue component
@Component
class MyComp extends Vue {
// Define component props
// props are passed from a parent component, (e.g. <MyComp :foo="'some value'" />)
// so we should not initialize its value here.
@Prop foo;
}On the above code, ES decorator initializes foo as undefined in constructor while TS decorator does not do anything for foo. This ES decorator behavior can cause a problem in some cases.
Case 1: Component prop unexpectedly overwritten with undefined
@Component
class MyComp extends Vue {
// Define prop `name`
@Prop name;
// Define component data `message`
// Its initial value is calculated with prop `name`
message = 'Hello, ' + this.name;
}In this example, this.name will be initialized by Vue as prop and expected to be used to calculate the component data message. This pattern is well seen in many Vue components and the canonical Vue API can do this.
The problem is that ES decorator overwrite name prop by undefined even though it already has a value. So message is initialized to 'Hello, undefined'. On the other hand TS decorator works as expected since it does not initialize name. This is a large blocker to include @Prop decorator in vue-class-component.
Case 2: Cannot distinguish initialized by undefined and not initialized
In vue-class-component, all class properties are collected as component data and they will be reactive properties. For this reason, we would like to distinguish these two cases, for example:
@Component
class MyComp extends Vue {
// not initialized
@Prop propValue;
// Watch changes of the value and call `someFunc` after some change.
// initialized by undefined
@Watch('someFunc') watchedValue = undefined;
someFunc () {
console.log('changed:', this.watchedValue)
}
}In the above example, @Prop propValue; is the same as before example, we don't want initialize propValue since its value is initialized by Vue. @Watch observes changes to watchedValue and call someFunc after watchedValue is changed. We want to initialize watchedValue and let it be reactive property because it is needed to observe a property.
In this case, propValue is declared as both prop and reactive property when we use ES decorator since propValue will be initialized by undefined and be enumerable. So vue-class-component cannot distinguish whether the user just uses it for decorator or declares as a reactive value.
For now, we made undefined as a special value (not to be converted to reactive property) to avoid this problem. But there are cases the users want to initialize them to undefined #39, #211
yyx990803
DanielRosenwasser
HerringtonDarkholme
mattheiler
ArmorDarks
yotamofek
ReinisV
Mikilll94
wycats
I've been contacted by @wycats (who is the champion of the ES decorator proposal at TC39) to provide feedback for the proposal from framework authors' perspective, and since this library (and
vue-property-decorators) is the primary use case where Vue leverages decorators, I'm hosting the thread here.I know there are a few discrepancies between ES and TS decorators, but am not 100% clear on the details. Ideally, I hope we can use
vue-class-componentandvue-property-decoratorsin both ES and TS contexts.Would appreciate thoughts from @ktsn and @kaorun343 on this topic.