A
Просто когда приходишь в компанию чтобы переписать с Ангуляра на Вью проект как-то странно начинать использовать классовые декораторы и делать код похожим на Ангуляр
Size: a a a
2020 June 06
T
и классовые компоненты на выходе - это всё те же обычные вьюшные объекты с methods, data, computed и так далее
T
для поддержки Vue 3 в них минимальное кол-во изменений нужно внести, если вообще нужно будет. ведь апи компонентов обратно совместимым будет
T
Просто когда приходишь в компанию чтобы переписать с Ангуляра на Вью проект как-то странно начинать использовать классовые декораторы и делать код похожим на Ангуляр
ну как бы тут от цели зависит)
если цель - избавиться от классов и декораторов (не буду спрашивать, зачем - допустим, так надо), то очевидно классовые компоненты с декораторами не подойдут ну никак)
если цель - избавиться от классов и декораторов (не буду спрашивать, зачем - допустим, так надо), то очевидно классовые компоненты с декораторами не подойдут ну никак)
A
Резонно, цели избавиться от классовых компонентов не стоит, но по негативному отношению Эвана к классовым компонентам создаётся ощущение, что дальше этот подход вымрет и превратится в Легаси код
T
Резонно, цели избавиться от классовых компонентов не стоит, но по негативному отношению Эвана к классовым компонентам создаётся ощущение, что дальше этот подход вымрет и превратится в Легаси код
а где он своё негативное отношение высказывал?
NG
Называется это даже не выстрел в ногу а выстрел в яйца
1000%
NT
Резонно, цели избавиться от классовых компонентов не стоит, но по негативному отношению Эвана к классовым компонентам создаётся ощущение, что дальше этот подход вымрет и превратится в Легаси код
этот подход останется в виде third-party library
NT
ровно как и сейчас
A
Переслано от Timofey
а где он своё негативное отношение высказывал?
T
Для тех, кто боится классов во Vue 3 и почему-то не могут проверить официальную информацию, а также для тех, кто утверждает, что поддержка под вопросом.
https://github.com/vuejs/vue-class-component/issues/402
https://github.com/kaorun343/vue-property-decorator/issues/294
https://github.com/vuejs/vue-class-component/issues/402
https://github.com/kaorun343/vue-property-decorator/issues/294
T
Это ты тёплое с мягким путаешь)
Тут говорится о поддержке классов из коробки. Это, действительно, забросили и похоже, что это просто нереально нормально реализовать. Собственно, скорее всего поэтому у ангуляра тоже декораторы, хоть и идут в комплекте с фреймворком.
Тут говорится о поддержке классов из коробки. Это, действительно, забросили и похоже, что это просто нереально нормально реализовать. Собственно, скорее всего поэтому у ангуляра тоже декораторы, хоть и идут в комплекте с фреймворком.
A
Хорошо, согласен, поддержка продолжится, но composition API в плане поддержки TS получше будет классовых компонентов с декораторами.
https://vue-composition-api-rfc.netlify.app/#adoption-strategy
https://vue-composition-api-rfc.netlify.app/#adoption-strategy
T
Хорошо, согласен, поддержка продолжится, но composition API в плане поддержки TS получше будет классовых компонентов с декораторами.
https://vue-composition-api-rfc.netlify.app/#adoption-strategy
https://vue-composition-api-rfc.netlify.app/#adoption-strategy
Ну тут кому что зайдёт. Я и не говорю, что композишн чем-то плох
A
Стало быть возникает вопрос: стоит ли сейчас в production использовать Composition API для лучшей поддержки TS?
T
Стало быть возникает вопрос: стоит ли сейчас в production использовать Composition API для лучшей поддержки TS?
ну просто выбрать что-то надо, оба варианта имеют право на жизнь
A
Ну и выбор между традиционным немного устаревшим классовым стилем и новым ещё возможно сырым composition API
T
ну в силу уже озвученных аргументов слово "устаревший" я бы не стал применять)
T
устареет скорее не классовый подход, а просто options API, который просто классовый с собой заберёт, поскольку одно основано на другом