Около полугода пришлось поработать над миграцией неработающего проекта на базе Vue 2 на проект Vue v.3.
Поскольку до сих пор работа с ним остаётся экзотикой, попробую описать состояние развития этого проекта в июле 2021 года, через 10 месяцев после релиза, и какие особенности встречались в этом не очень большом проекте в процессе миграции.
Будет интересно разработчикам и менеджерам, планирующим перевод проектов на Vue3, чтобы оценить трудоёмкость такого перехода. (TLDR — для перехода на Vue 3 сейчас многие фреймворки уже имеют свои версии с поддержкой Vue3. Сам переход особых трудностей не представляет, благодаря поддержке старого Options API и совместимости компонентов на разных API. Но вполне возможно, что время разработки увеличится за счёт ручной доработки отдельных компонентов, для которых авторы не написали версии поддержки. Какая-то значительная часть таких пакетов NPM имеется и останется, но нет проблем основываться на нативных версиях пакетов или написать части своего проекта по-другому, без использования старых пакетов. Активно поддерживаемые пакеты часто уже мигрировали и проблем не создают. Эту неопределённость каждого своего проекта необходимо вначале оценить и уметь писать компоненты.)
Особое внимание хочу уделить не проекту, а месту Vue 3 в экосистеме разработок среди других. Описать, что увиделось интересным и что удивляет.
Второй фактор, влиявший на выбор движка — отсутствие документации. Она не была нужна, поскольку ключевой разработчик (из совладельцев) знает проект и мог бы заново описать в процессе разработки бизнес-требования. В то же время, будет меньше вопросов, если код старого проекта использовался бы для создания нового. Поэтому из вариантов движка остаются Vue 2 или Vue 3.
Про Vue 2 — понятно, что разработчики обещают его поддержку 2 года после выхода 3-й версии. И рано или поздно переходить придётся. Или ваш проект уже станет неактуальным и через 3 года напишут новый? Эти вопросы было необходимо оценить.
Относительно Vue 3 — хотя тогда прошло от релиза несколько месяцев (3-4), фреймворки были в большинстве в бета-стадии поддержки движка Vue 3, а пара важных (Vuetify и какой-то другой) — даже к альфе на тот момент не приступали.
В этом был некоторый вопрос — понятно, что лучше делать на Vue 3, но насколько много придётся переписывать и переделывать — было неизвестно. Надо было попробовать запустить страницы проекта и оценить объём доработок. В худшем случае пришлось бы много переписывать покомпонентно, в лучшем — большая часть проекта использовалась бы (в Options API), и вопрос стоял в совместимости по-разному написанных компонентов. Например, мультиязычная поддержка была уже на Composition API.
Через неделю миграции первая страница на подменённом движке уже начала работать, на Options, при этом i18n была на Composition, а позже и верификации на Composition были интегрированы с проектом. И ещё через неделю стало ясно, что 2-3 компонента (чекбоксы, радиокнопки, селекты) придётся дорабатывать. Потом добавился ColorPicker, за основу которого пришлось взять нативный NPM-пакет. Но многое можно было унаследовать от старого кода, сэкономив за счёт миграции, а не переписывания, по оценке, пару месяцев (важно, что документации вообще не было, сам код был документацией, и он непрерывно рефакторился в процессе разработки нового проекта).
Ещё момент несовместимости — сборщиком проекта был выбран Vite (на Rollup, написан специально под Vue3 разработчиками), и некоторые возможности, которые давал Webpack для некоторых пакетов (графики) не могли использоваться, хотя потом можно было бы разобраться. Сборщик Vue3 на Webpack есть (vue-loader-v16), но интересно было обойтись без него. В итоге, пакет с графиками работает, но не оптимизирован (это было не первоочерёдно).
Ещё, мы на раннем этапе рассматривали возможность перехода в будущем на фреймворк — Quasar, например, для облегчения мобильной разработки. Оказалось, что примерно в феврале много команд разработки пакетов уже работали над своими версиями для Vue3 и были в бета-стадиях. Quasar был среди них. Vuetify обещал сделать в течение 2021 года и пока сроки соблюдает, но у остальных стадии готовности — гораздо лучше.
Сейчас, в июле 2021
Вообще-то, если смотреть планы в динамике, то у всех, включая головной проект Vue 3 — планы запаздывают и отодвигаются. Например, при релизе Vue3 обещали к концу года поместить этот проект на главную. До сих пор (июль 2021 года) на главной vuejs.org находится проект VueJS 2.x, а вверху — отсылка на страницу с Vue3: v3.vuejs.org. И помним, что и момент релиза 3-й версии Vue был передвинут примерно на год относительно начальных планов. Связано, как объясняли в своё время, в поддержке технологий «хуков» (тот самый Composition API), которые одновременно внедрились и развивались в React в то время.
В общем — жить и разрабатывать на Vue3 можно, и с каждым месяцем крепнут основания для этого утверждения.
Несомненно, будут старые интересные компоненты, которые не будут далее развиваться своими разработчиками. А новые не сразу и не всегда появятся. Придётся что-то сочинять, переписывать. Весь старый пакет обычно невыгодно переписывать, если вы не имеете планов его вести дальше. Потому что часто пакеты рассчитаны на множество настроек для разных случаев использования, а вам нужен один случай. Даже патч невыгоден из-за лишнего кода пакета, хотя возможен.
Поэтому, при переходе на новую технологию, как всегда, придётся оценивать больше неопределённостей, чем делать то же, оставаясь на старой версии или выбирая другой развитый фреймворк типа React.
Совмещать 2 API в одном компоненте не приходилось, за исключением вызова вложенных компонентов, но применение разных API в разных компонентах не вызывает проблем. Правда, попытка совмещения двух тегов скрипта была успешной, но был серьёзный минус, что не удалось найти между ними способ передачи параметров иной, чем через глобальный объект. Это примерно то же, что пользоваться стором (this.$store) и достаточно типично для Vue. Но хотелось бы видеть предусмотренный в документации шлюз между Composition и Options.
Например, прикручивал валидатор на Composition API. Оказывается, что из setup-скрипта валидатор передаёт правила валидации в переменной value. Чтобы оставить привычное $v, понадобилось назвать: const {value: v$} = useVuelidate({...}), а потом передать её через глобальную переменную. (Не исключено, что тогда переменные будут конфликтовать, и передавать придётся через разные переменные.) Потом, в обычном не сетапном скрипте в Options API имеем доступ к этой переменной.
Удобно, что теперь не обязательно иметь 1 корневой узел элемента в <template>. Глубина вложенностей укорачивается, суть не меняется.
Доступ к языковой функции словаря в шаблоне компонента — через t(...). Доступ к ней в скрипте — по this.$t(...).
Vite запускается нормально, без сюрпризов. В vite.config.ts можно написать свой предварительный NodeJS код, но во многом сборщик всё делает сам. Например, собирает все стили без напоминаний, где что лежит, sass компилирует и складывает в бандл.
Если в defineConfig написать build: { minify: !1 }, бандлы соберутся неупакованными и чуть быстрее на пару секунд.
В Vite-вотчере не удаётся корректно на лету компилировать сложные доработки скриптов. Вотчер вешается, его приходится перезапускать. Это не удивительно — в Реакте на сложных моментах вотчер тоже периодически вешается, но Vite, специально заточенный под Vue3, давал надежду, что будет корректно работать и в сложных случаях, почему его и пробовал, и пользуюсь, но чаще в режиме сборки-запуска (не вотчера). Возможно, его допилят, работа над ним продолжается, версии растут. Других проблем от него, впрочем, не было.
Смотрим, сколько примерно раз за последнюю неделю скачали группу версий Vue 3.x.x
(Примерно 1.5 месяца назад такое сравнение давало соотношение около 10-12%, а сейчас уже 16%.)
Однако, и 12%, и 16% после 9 месяцев релиза — это весьма скромно и мало.
С этим, видимо, связано тоже решение разработчиков не ставить Vue3 пока что на главную страницу. А причиной этого — не столь быстрое «победное шествие» движка. При этом, надо учесть, что живых боевых проектов на Vue3 будет сильно меньше, а живых боевых на Vue2 — несколько больше, потому что часть скачиваний — не для разработки, а для работы. Итого, число разрабатываемых сейчас проектов на Vue3 оцениваем в 8-12% (с некоторой ошибкой из-за оценочности) от разрабатываемых и поддерживаемых (патчи, обновления) проектов на Vue2.
Рассмотрим другой обещанный способ оценки «занятости разработчиков» во Vue3 — по числу вакансий.
Недели 4 назад я оценивал число компаний, ищущих разработчиков на React, на Vue, на Vue 3 в частности, и на Angular (других практически не встречалось). Специально не считал, поэтому приведу грубую оценку.
Разработчиков на React ищет большинство компаний, 60-65%. С хуками, конечно. На Angular — примерно 15-10%. Такое ощущение, что мелкие проекты на Ангуляре не делают. На Vue — оставшиеся 25% (количественно — штук 40 вакансий). При этом с упоминанием Vue3 было всего 4 вакансии. Те же приблизительные 10% разработок.
Из 4 вакансий только в 2 знание Vue3 было приоритетным, т.е. брали под уже разрабатываемый или планируемый проект на Vue3. В 2 остальных Vue3 упоминался как «плюс».
Когда смотрели вакансии в январе 2021, то по примерно такой же выборке проектов под Vue было несколько больше (процентов 30), а Vue3 упоминала только 1 вакансия с корейскими заказчиками.
Источник статьи: https://habr.com/ru/post/568248/
Поскольку до сих пор работа с ним остаётся экзотикой, попробую описать состояние развития этого проекта в июле 2021 года, через 10 месяцев после релиза, и какие особенности встречались в этом не очень большом проекте в процессе миграции.
Будет интересно разработчикам и менеджерам, планирующим перевод проектов на Vue3, чтобы оценить трудоёмкость такого перехода. (TLDR — для перехода на Vue 3 сейчас многие фреймворки уже имеют свои версии с поддержкой Vue3. Сам переход особых трудностей не представляет, благодаря поддержке старого Options API и совместимости компонентов на разных API. Но вполне возможно, что время разработки увеличится за счёт ручной доработки отдельных компонентов, для которых авторы не написали версии поддержки. Какая-то значительная часть таких пакетов NPM имеется и останется, но нет проблем основываться на нативных версиях пакетов или написать части своего проекта по-другому, без использования старых пакетов. Активно поддерживаемые пакеты часто уже мигрировали и проблем не создают. Эту неопределённость каждого своего проекта необходимо вначале оценить и уметь писать компоненты.)
Кратко о проекте
Этот проект — типичный личный кабинет для пользователей с невысокой нагрузкой (до тысяч аккаунтов; одновременно работающих — не более сотен). Имеется множество настроек серверного движка, которым они управляют, и мини-проектов, которые они делают. Подробностей уточнять не будем, поскольку это бизнес и NDA. На фронтенд хватало одного разработчика, по бекенду взаимодействовал с небольшой группой. В перспективе, в проект понадобится встроить роль администратора (сейчас — роли «аноним» и «пользователь»), так как эти мини-проекты требуют модерации и обработки данных из БД, не только просмотр и правка таблиц — без фронтенд-админки не обойтись.Особое внимание хочу уделить не проекту, а месту Vue 3 в экосистеме разработок среди других. Описать, что увиделось интересным и что удивляет.
Как выбирали движок
Был ранее созданный проект на основе Vue 2, но движок (на PHP) его к началу 2021 года потерял актуальность и было решено его переписать. В то же время, разработчики бекенда имели некоторое представление о Vue, поэтому вопрос о смене фреймворка не стоял — Vue был для всех удобнее.Второй фактор, влиявший на выбор движка — отсутствие документации. Она не была нужна, поскольку ключевой разработчик (из совладельцев) знает проект и мог бы заново описать в процессе разработки бизнес-требования. В то же время, будет меньше вопросов, если код старого проекта использовался бы для создания нового. Поэтому из вариантов движка остаются Vue 2 или Vue 3.
Про Vue 2 — понятно, что разработчики обещают его поддержку 2 года после выхода 3-й версии. И рано или поздно переходить придётся. Или ваш проект уже станет неактуальным и через 3 года напишут новый? Эти вопросы было необходимо оценить.
Относительно Vue 3 — хотя тогда прошло от релиза несколько месяцев (3-4), фреймворки были в большинстве в бета-стадии поддержки движка Vue 3, а пара важных (Vuetify и какой-то другой) — даже к альфе на тот момент не приступали.
В этом был некоторый вопрос — понятно, что лучше делать на Vue 3, но насколько много придётся переписывать и переделывать — было неизвестно. Надо было попробовать запустить страницы проекта и оценить объём доработок. В худшем случае пришлось бы много переписывать покомпонентно, в лучшем — большая часть проекта использовалась бы (в Options API), и вопрос стоял в совместимости по-разному написанных компонентов. Например, мультиязычная поддержка была уже на Composition API.
Через неделю миграции первая страница на подменённом движке уже начала работать, на Options, при этом i18n была на Composition, а позже и верификации на Composition были интегрированы с проектом. И ещё через неделю стало ясно, что 2-3 компонента (чекбоксы, радиокнопки, селекты) придётся дорабатывать. Потом добавился ColorPicker, за основу которого пришлось взять нативный NPM-пакет. Но многое можно было унаследовать от старого кода, сэкономив за счёт миграции, а не переписывания, по оценке, пару месяцев (важно, что документации вообще не было, сам код был документацией, и он непрерывно рефакторился в процессе разработки нового проекта).
Ещё момент несовместимости — сборщиком проекта был выбран Vite (на Rollup, написан специально под Vue3 разработчиками), и некоторые возможности, которые давал Webpack для некоторых пакетов (графики) не могли использоваться, хотя потом можно было бы разобраться. Сборщик Vue3 на Webpack есть (vue-loader-v16), но интересно было обойтись без него. В итоге, пакет с графиками работает, но не оптимизирован (это было не первоочерёдно).
Ещё, мы на раннем этапе рассматривали возможность перехода в будущем на фреймворк — Quasar, например, для облегчения мобильной разработки. Оказалось, что примерно в феврале много команд разработки пакетов уже работали над своими версиями для Vue3 и были в бета-стадиях. Quasar был среди них. Vuetify обещал сделать в течение 2021 года и пока сроки соблюдает, но у остальных стадии готовности — гораздо лучше.
Сейчас, в июле 2021
- Quasar 2.0.2 уже месяц, как в релизе www.npmjs.com/package/quasar/v/2.0.2 .
- Vuetify 3.0.0-alpha.9 www.npmjs.com/package/vuetify/v/3.0.0-alpha.9 Ну, он сразу заявлял, что сильно спешить не будет, уже 3 месяца в альфе и соблюдает сроки.
Вообще-то, если смотреть планы в динамике, то у всех, включая головной проект Vue 3 — планы запаздывают и отодвигаются. Например, при релизе Vue3 обещали к концу года поместить этот проект на главную. До сих пор (июль 2021 года) на главной vuejs.org находится проект VueJS 2.x, а вверху — отсылка на страницу с Vue3: v3.vuejs.org. И помним, что и момент релиза 3-й версии Vue был передвинут примерно на год относительно начальных планов. Связано, как объясняли в своё время, в поддержке технологий «хуков» (тот самый Composition API), которые одновременно внедрились и развивались в React в то время.
Что ещё из интересных пакетов
- Element Plus — A Vue.js 3.0 UI library: www.npmjs.com/package/element-plus 1.0.2-beta.55 сейчас и в бете находится 8 месяцев — с конца ноября 2020. начинать разрабатывать на нём можно.
- ant-design-vue — 2.2.2 сейчас и поддерживается релизная версия уже 5 месяцев, с 2.0.0 от февраля 2021.
В общем — жить и разрабатывать на Vue3 можно, и с каждым месяцем крепнут основания для этого утверждения.
Несомненно, будут старые интересные компоненты, которые не будут далее развиваться своими разработчиками. А новые не сразу и не всегда появятся. Придётся что-то сочинять, переписывать. Весь старый пакет обычно невыгодно переписывать, если вы не имеете планов его вести дальше. Потому что часто пакеты рассчитаны на множество настроек для разных случаев использования, а вам нужен один случай. Даже патч невыгоден из-за лишнего кода пакета, хотя возможен.
Поэтому, при переходе на новую технологию, как всегда, придётся оценивать больше неопределённостей, чем делать то же, оставаясь на старой версии или выбирая другой развитый фреймворк типа React.
Что интересного было в деталях разработки
i18n (языковая поддержка). Внедрили пакет одним из первых, и там понадобилось совмещать старый и новый API. Применил нестандартное решение в виде объявления двух блоков <script lang=«ts»> — простой и следом за ним — с атрибутом setup: <script setup lang=«ts»>. От этого компилятор немного ругается, не ожидая 2 блоков скрипта, но работает. Выполнять их надо в 2 разных местах скомпилированного компонента, на что указывает атрибут setup.Совмещать 2 API в одном компоненте не приходилось, за исключением вызова вложенных компонентов, но применение разных API в разных компонентах не вызывает проблем. Правда, попытка совмещения двух тегов скрипта была успешной, но был серьёзный минус, что не удалось найти между ними способ передачи параметров иной, чем через глобальный объект. Это примерно то же, что пользоваться стором (this.$store) и достаточно типично для Vue. Но хотелось бы видеть предусмотренный в документации шлюз между Composition и Options.
Например, прикручивал валидатор на Composition API. Оказывается, что из setup-скрипта валидатор передаёт правила валидации в переменной value. Чтобы оставить привычное $v, понадобилось назвать: const {value: v$} = useVuelidate({...}), а потом передать её через глобальную переменную. (Не исключено, что тогда переменные будут конфликтовать, и передавать придётся через разные переменные.) Потом, в обычном не сетапном скрипте в Options API имеем доступ к этой переменной.
Удобно, что теперь не обязательно иметь 1 корневой узел элемента в <template>. Глубина вложенностей укорачивается, суть не меняется.
Доступ к языковой функции словаря в шаблоне компонента — через t(...). Доступ к ней в скрипте — по this.$t(...).
Vite запускается нормально, без сюрпризов. В vite.config.ts можно написать свой предварительный NodeJS код, но во многом сборщик всё делает сам. Например, собирает все стили без напоминаний, где что лежит, sass компилирует и складывает в бандл.
Если в defineConfig написать build: { minify: !1 }, бандлы соберутся неупакованными и чуть быстрее на пару секунд.
В Vite-вотчере не удаётся корректно на лету компилировать сложные доработки скриптов. Вотчер вешается, его приходится перезапускать. Это не удивительно — в Реакте на сложных моментах вотчер тоже периодически вешается, но Vite, специально заточенный под Vue3, давал надежду, что будет корректно работать и в сложных случаях, почему его и пробовал, и пользуюсь, но чаще в режиме сборки-запуска (не вотчера). Возможно, его допилят, работа над ним продолжается, версии растут. Других проблем от него, впрочем, не было.
Оценка занятости разработчиков на Vue 2 и 3
Давайте количественно оценим размер занятости разработчиков на проекте Vue 3 относительно Vue 2. Оценим по количеству скачиваний проектов на Npmjs.org. Потом, придётся оценить, что часть скачиваний — это перезагрузки старых проектов, поэтому — не все скачивания считать разработкой.… Но затем будет описан ещё один способ оценки.Смотрим, сколько примерно раз за последнюю неделю скачали группу версий Vue 3.x.x
- Vue3 (11-17 июля 2021): 4120 + 102097 + 1409 + 22898 + 19770(3.1.x) + 44221(3.0.11) + 30000 ещё = 195 тыс.
- Vue2 2.6.x (11-17 июля 2021): 680911 + 350759 + 164266 + 30000 = 1 млн. 200 тыс.
(Примерно 1.5 месяца назад такое сравнение давало соотношение около 10-12%, а сейчас уже 16%.)
Однако, и 12%, и 16% после 9 месяцев релиза — это весьма скромно и мало.
С этим, видимо, связано тоже решение разработчиков не ставить Vue3 пока что на главную страницу. А причиной этого — не столь быстрое «победное шествие» движка. При этом, надо учесть, что живых боевых проектов на Vue3 будет сильно меньше, а живых боевых на Vue2 — несколько больше, потому что часть скачиваний — не для разработки, а для работы. Итого, число разрабатываемых сейчас проектов на Vue3 оцениваем в 8-12% (с некоторой ошибкой из-за оценочности) от разрабатываемых и поддерживаемых (патчи, обновления) проектов на Vue2.
Рассмотрим другой обещанный способ оценки «занятости разработчиков» во Vue3 — по числу вакансий.
Недели 4 назад я оценивал число компаний, ищущих разработчиков на React, на Vue, на Vue 3 в частности, и на Angular (других практически не встречалось). Специально не считал, поэтому приведу грубую оценку.
Разработчиков на React ищет большинство компаний, 60-65%. С хуками, конечно. На Angular — примерно 15-10%. Такое ощущение, что мелкие проекты на Ангуляре не делают. На Vue — оставшиеся 25% (количественно — штук 40 вакансий). При этом с упоминанием Vue3 было всего 4 вакансии. Те же приблизительные 10% разработок.
Из 4 вакансий только в 2 знание Vue3 было приоритетным, т.е. брали под уже разрабатываемый или планируемый проект на Vue3. В 2 остальных Vue3 упоминался как «плюс».
Когда смотрели вакансии в январе 2021, то по примерно такой же выборке проектов под Vue было несколько больше (процентов 30), а Vue3 упоминала только 1 вакансия с корейскими заказчиками.
Источник статьи: https://habr.com/ru/post/568248/