``` Data: (): State => ({ highlightClass: '', isCollapsed:

false
}),

setup (props) {
watch(props.payload, (next, prev) => {
this.highlightClass = prev.priceUsd > next.priceUsd ? 'negative' : 'positive'
})
},
```

как мне внутри watch обновить стейт? такой код выдает ошибку TypeError: Cannot set property 'highlightClass' of undefined

не нужно юзать стрелочную функцию, если ты хочешь иметь доступ к this а еще лучше не мешать Composition API и Options API, а то получится каша

можно пожулайста пример правильного кода для этого кейса?

если ты хочешь юзать Options API, то убери сетап и вынеси вотчер отдельно data: () => …. watch: { payload(next, prev) { this.highlightClass = … } },

такой пробовал, почему-то в next и prev объекты одинаковые 🤷

А я как-то посидел, подумал, и не вижу чего-то криминального в смешивании. Описывать компоненты просто в Composition API может быть неудобно. Если он не разделяется на части, то вместо структурированного Options получается большая каша из кода в одной огромной функции setup. Composition нужен для некоторых отдельных задач. Когда надо подключить какие-то компосаблы, или для конкретных компонентов. Переводить весь компонент, написанный на Options в Composition из-за подключения одного маленького компосабла по мне не очень интересно. Как и писать в целом все-все компоненты в Composition, если мы используем где-то хотя бы один компосабл

Они не могут быть одинаковые. Отслеживание во Vue не срабатывает, если значение изменилось на такое же, как было

на самом деле наоборот, как по мне, в сетапе гораздо удобнее структурировать всю логику в одном месте, а если компонент большой, то это можно разнести по composable’ам с Options постоянно получается так, что функционал разнесен по разным участкам компонента и нужно туда-сюда скроллить, у меня это постоянно вызывало душевную боль в последнем проекте я перешел на тройку и юзаю исключительно Composition API, сейчас у меня где-то 200+ компонентов, написанных на нем, среди которых есть и огромные, и крошечные, - и все прям супер удобно, не сравнить с Options API

Ну не знаю. Мне структурирование видеть отдельно блоки с состоянием, отдельно вычисления, отдельно отслеживание, отдельно методы и т.д. в заранее определённом порядке, чем всё в одной простыне кода) А разделять компонент на части актуально, если эти части или имеют смысл сами по себе, или если компонент очень большой, и имеет у себя подзадачи

у меня часто получается так, что есть несколько каких-то связанных частей в компоненте, которые можно удобно структурировать даже без composable’ов сначала идет одна часть, у которой свои вотчеры, свои компьютед, свои данные, а ниже - другая, у которой все свое по такой структуре очень легко ориентироваться и вся логика как на ладони

потому что vue тебе отдает в prev и next одну и ту же копию объекта, он не клонирует его за тебя

> сначала идет одна часть, у которой свои вотчеры, свои компьютед, свои данные, а ниже - другая А между ними граница есть?

граница в каком смысле?)

Ну, выглядит это всё, как большая куча кода, или явно видно, вот первая часть, а вот другая?

логически можно понять по названиям переменных + всегда есть пробел между этими частями, который помогает глазами уловить, что тут идет уже что-то другое обычно такие компоненты не очень большие по объему, поэтому разделять такие части - вообще не проблема все большие компоненты разносятся по composable’ам, а маленькие редко превышают 200 строк (вместе со стилями и шаблоном)