Мне прислали вопрос по моему докладу:
Тема на самом деле куда обширнее чем кажется на первый взгляд, Именно поэтому я добавил ее в блок "потенциальный доклад по теме", Тут будет моя адаптация ответа.
Так как композаблы сами в себе альтернатива ООП заточенная конкретно под нужды Vue. Они уже используют фичи соответствующие потребностям и отсекают вещи которые не особо нужны.
Выше уже было мое сравнение композаблов и ООП, потом в отдельных чатах эта тема прорабтывалась куда подробнее. Но тут я сосредоточусь на минусах классов как замены композаблов
1) Классы - не vue way. Ни в одном гайде не будет такого использования. Вы увеличите время онбоардинга, а разработчикам придется куда сложнее с точки зрения приспосабливаемости к проекту, Библиотеки также не адаптированы под данный подход. В одном из случаев вам придется писать огромную портянку с оберткой композаблов в классы, в другом у вас будет адская смесь из классов и композаблов. Выдерживать единый стиль в таких проектах кратно сложнее.
2) Нет четко выработанных практик о том как БЕЗОПАСНО использовать смесь Vue и классов. Высока вероятность получения хрупкого кода, потери реактивности и лапши, При этом опять же у вас не будет гайдов, как правильно это использовать в том или ином случае. Реактивность Vue не дружит полноценно с классами. Например private property несоввместимы с proxy, вам придется полагаться только на TS зоны видимости, но и с ними будут свои нюансы
3)ООП дает избыточные инструменты которые будут только мешать при использовании Vue, они хуже связываются с его жизненным циклом. Наследование, instanceof и тп просто бесполезны. А вот классическую деструктуризацию использовать сложнее
4) Вы не получите никаких бенефитов от данного подхода. Все что дает ООП и реально нужно, то возможно использовать с композаблами и так.
Так стоит ли это того? Классы часто берут по привычке, либо если почувствовали в себе труъ-инженеров (а это буквально самое страшное что может случиться с проектом, самые запущенные случаи которые видел, когда кто-то посчитал себя истинным инженером и нагородил такой лапши, что проще проект выкинуть и переписать заново, чем править его логику)
Почему же это использовали со Vue2?
- А потому что других вариантов адекватных не было. Как раз из-за отсутсвия композаблов выносить логику из компонентов для переиспользования было прям сильно сложнее, а миксины были еще хуже как решение. Вот собственно и все
Когда классы+Vue ок? Когда вы используете сторонние специализированные инструменты которые уже заточены под классовое ооп. Например, если вы подключили Mobx (хотя особого смысла я в этом тоже не вижу)
почему нежелательно использовать классы вместо компосаблов.
Тема на самом деле куда обширнее чем кажется на первый взгляд, Именно поэтому я добавил ее в блок "потенциальный доклад по теме", Тут будет моя адаптация ответа.
Так как композаблы сами в себе альтернатива ООП заточенная конкретно под нужды Vue. Они уже используют фичи соответствующие потребностям и отсекают вещи которые не особо нужны.
Выше уже было мое сравнение композаблов и ООП, потом в отдельных чатах эта тема прорабтывалась куда подробнее. Но тут я сосредоточусь на минусах классов как замены композаблов
1) Классы - не vue way. Ни в одном гайде не будет такого использования. Вы увеличите время онбоардинга, а разработчикам придется куда сложнее с точки зрения приспосабливаемости к проекту, Библиотеки также не адаптированы под данный подход. В одном из случаев вам придется писать огромную портянку с оберткой композаблов в классы, в другом у вас будет адская смесь из классов и композаблов. Выдерживать единый стиль в таких проектах кратно сложнее.
2) Нет четко выработанных практик о том как БЕЗОПАСНО использовать смесь Vue и классов. Высока вероятность получения хрупкого кода, потери реактивности и лапши, При этом опять же у вас не будет гайдов, как правильно это использовать в том или ином случае. Реактивность Vue не дружит полноценно с классами. Например private property несоввместимы с proxy, вам придется полагаться только на TS зоны видимости, но и с ними будут свои нюансы
3)ООП дает избыточные инструменты которые будут только мешать при использовании Vue, они хуже связываются с его жизненным циклом. Наследование, instanceof и тп просто бесполезны. А вот классическую деструктуризацию использовать сложнее
4) Вы не получите никаких бенефитов от данного подхода. Все что дает ООП и реально нужно, то возможно использовать с композаблами и так.
Так стоит ли это того? Классы часто берут по привычке, либо если почувствовали в себе труъ-инженеров (а это буквально самое страшное что может случиться с проектом, самые запущенные случаи которые видел, когда кто-то посчитал себя истинным инженером и нагородил такой лапши, что проще проект выкинуть и переписать заново, чем править его логику)
Почему же это использовали со Vue2?
- А потому что других вариантов адекватных не было. Как раз из-за отсутсвия композаблов выносить логику из компонентов для переиспользования было прям сильно сложнее, а миксины были еще хуже как решение. Вот собственно и все
Когда классы+Vue ок? Когда вы используете сторонние специализированные инструменты которые уже заточены под классовое ооп. Например, если вы подключили Mobx (хотя особого смысла я в этом тоже не вижу)