С выходом Composition API в Vue появилось новые возможности повторного использования кода. Больше нет необходимости в миксинах, компонентах высшего порядка и прочих “хаках”, если вам нужно вынести общую логику для нескольких компонентов. Но что если у вас есть нереактивный сервис, инкапсулирующий бизнес-логику, а переписывать все на composition api не хочется?
К примеру возьмем простой класс с состоянием:
export class MyService {
foo: Object = {}
setFoo (foo: Object) {
this.foo = foo
}
}
В нем все прекрасно, но что если мы хотим сделать его свойство реактивным? Согласно документации, мы можем сделать, например, вот так:
import { Ref, ref } from 'vue'
export class MyService {
foo: Ref<Object> = ref({})
setFoo (foo: Object) {
this.foo.value = foo
}
}
Вроде бы тоже неплохо, но если ваш сервис большой и иерархичный, переводить каждое свойство в ref будет трудно и больно. Тут на помощь приходят декораторы Typescript:
export class MyService {
@Reactive foo: Object = {}
setFoo (foo: Object) {
this.foo = foo
}
}
Успех! Наше свойство реактивно, но теперь уже без манипуляций c ref-ами. Как это работает? Рассмотрим сам декоратор:
import { shallowRef } from 'vue'
function initRefs (target: any, key: string, value ?: any) {
target.__refs = target.__refs ?? {}
if (!target.__refs[key]) {
target.__refs[key] = shallowRef(value)
}
}
export function Reactive (target: any, key: string): void {
Object.defineProperty(target, key, {
configurable: true,
enumerable: true,
get () {
initRefs(this, key)
return this.__refs[key].value
},
set (value) {
initRefs(this, value, key)
this.__refs[key].value = value
}
})
}
Благодаря Object.defineProperty, свойство попросту заменяется геттером и сеттером, обращающимся к ref-у, который хранится в том же классе. Его инициализация происходит при первом чтении либо записи.
Заключение
Декораторы - мощный инструмент, позволяющий вынести низкоуровневый код на уровень инфраструктуры и не засорять им приложение. Но какие минусы у такого подхода?
Декораторы все еще являются экспериментальной функцией, и ее реализация в будущем может измениться, о чем говорится в документации. Кроме того, для их работы необходимо явно проставить параметр
experimentalDecorators
.Этот подход похож на магию и прячет нюансы реализации от разработчика, что может привести к неожиданным багам и непредсказуемому поведению.
Это не работает с SSR из коробки, хотя это преодолимая проблема, например, с помощью Nuxt и его
ssrRef
Тем не менее, лично мне такой путь нравится, он красив и элегантен и не накладывает драконовских ограничений. А как вы считаете? Комментарии и предложения к подходу охотно принимаются.