К настоящему времени вы, скорее всего, слышали о Vue 3 — следующей основной версии Vue. Более того, учитывая длительный предрелизный период Vue 3, возможно, вы уже использовали его.

Vue 3 вносит в таблицу множество изменений. Переписывание TypeScript, Composition API, фрагменты, улучшенная поддержка JSX — это лишь некоторые из моих лучших вариантов. Неудивительно, почему так много разработчиков уже запрыгнули в поезд на всех парах, несмотря на постоянный статус бета-версии.

С учетом сказанного, в этой группе разработчиков мы можем выделить 2 отдельных разработчиков: один сразу переходит на Vue 3, а другой уже глубоко погрузился во Vue 2 и хочет продолжить миграцию на пожинать плоды.

Как человек, который находится где-то между этими двумя, у меня есть несколько советов для обеих групп. Я уже много работал с Vue 2 и его экосистемой в прошлом и только недавно вернулся к использованию Vue 3 для поддержки моего инструмента для ведения блога CodeWrite. Этот опыт дает мне совершенно особый взгляд на переход с Vue 2 на Vue 3, которым сегодня я хотел бы поделиться с вами в виде полезных советов!

1. Помните об экосистеме

Я думаю, что документы официальной миграции недостаточно подчеркивают это. Vue 3 поддерживает большую часть API Vue 2, но в нем все еще есть некоторые критические изменения. И из-за этих изменений вы теряете доступ почти ко всей экосистеме Vue 2.

А вот это серьезный недостаток. Если вы полагаетесь на какую-либо стороннюю библиотеку, ориентированную на Vue 2, вам придется либо дождаться ее обновления, либо обойти ее самостоятельно. При использовании, например, Vuetify (где поддержка Vue 3 в настоящее время находится в альфа-версии), второй вариант на самом деле не вариант, и вам придется подождать, пока он не будет обновлен.

Когда я начинал CodeWrite с чистого листа, меня не сдерживали какие-либо привязки к экосистеме. Тем не менее, влияние было заметным, и я был сильно ограничен в выборе инструментов. Однако, потратив некоторое время на поиск независимых от фреймворка альтернатив и используя Tailwind CSS в качестве моей альтернативы библиотеки компонентов пользовательского интерфейса, я смог получить преимущества Vue 3, независимость от фреймворка и все, что мне нужно. необходимо, чтобы сделать CodeWrite вещь.

2. Работа с критическими изменениями

Критические изменения влияют не только на экосистему — они напрямую влияют на ваш код. Вот почему вы должны быть хорошо подготовлены и хорошо осведомлены о них.

Было бы идеально заранее узнать, что придется изменить. Проверьте свой код, проведите исследование, составьте список. Вы почти наверняка не справитесь со всеми проблемами, но справитесь с самыми серьезными.

Вы можете просмотреть полный список критических изменений в официальной документации. Самые большие из них:

  • Изменения в Global API и его древовидная реструктуризация
  • Изменения в поведении v-model (могут быть проблематичными)
  • destroyed и beforeDestroy переименование в unmount и beforeUnmount соответственно
  • Общие изменения во внутренних и «низкоуровневых» API (актуально, только если вы использовали некоторые пользовательские функции, которые взаимодействовали с этими API в Vue 2)

Имейте в виду, что это мой выбор, основанный на моем опыте, и ваш пробег может отличаться. Тем не менее, дело в том, что новаторские изменения — это то, с чем следует быть очень осторожным, даже до того, как начнется процесс миграции.

3. Внедряйте новые функции постепенно (но быстро)

Это может быть очевидно, но есть разные стратегии для решения этой проблемы. Итак, действительно ли вам нужно внедрять новые функции постепенно, и если да, то почему и как? В конце концов, это основная причина для обновления, не так ли?

Обычно наиболее распространенным правилом является начинать с новых компонентов и постепенно преобразовывать старые. Это вполне разумно, но, как помешанный на чистом коде и чистой архитектуре, я готов сделать все возможное, чтобы сделать мой код непротиворечивым.

Я считаю этот подход одинаково хорошим (лучшим для меня), так как преобразование моих старых компонентов в новый API или стиль кода не требует особых усилий. В некоторых случаях вы можете даже автоматизировать его.

Для Vue 3 примером такого изменения «для всей кодовой базы» может быть новый Composition API или синтаксический сахар <script setup>. Конечно, преобразование из Options API в Composition API может показаться не «бездумной», автоматизируемой задачей, но становится все проще, когда вы конвертируете один или два компонента.

Теперь я знаю, что это может быть не очень хорошей идеей для больших кодовых баз с сотнями компонентов. Однако суть в том, что не оставляйте свой старый код ржаветь. Начните преобразовывать его как можно скорее. Не ждите появления потребности в новых компонентах. Стремитесь к последовательности и чистоте.

4. Заранее планируйте смелые шаги

В связи с постепенным внедрением функций давайте поговорим о планировании. Точнее — о планировании смелых ходов.

Во-первых, что я имею в виду под «смелыми шагами»? Ну, например, принятие TypeScript. Vue 3 был переписан с его использованием, и теперь поддержка превосходна. То же самое можно сказать и о других официальных библиотеках, и, вероятно, это применимо к большей части новой экосистемы, которая создается или обновляется для Vue 3.

А внедрение Composition API или, что еще более безумно — JSX (поддержка его тоже стала лучше) — тоже смелый шаг? Для меня — нет. Это связано с тем, что в основном это просто принятие новой функции — что-то ожидаемое во время обновления, но самое главное — потому что это влияет только на просмотр часть вашего проекта.

В хорошо структурированном проекте ваша «бизнес-логика» должна быть отделена от представления. Ваши компоненты Vue не должны иметь дело с подключением к серверной части или загрузкой ресурсов, а должны просто правильно отображать текущее состояние.

Итак, TypeScript, без сомнения, попадает в эту категорию, так как влияет на всю вашу кодовую базу (включая бизнес-логику). Конечно, вы можете адаптировать его постепенно, но вам следует стремиться к полному охвату TypeScript по всем направлениям, если вы это сделаете.

Да, и поскольку это субъективный список, я могу сказать, что вам следует перейти на TypeScript. Это упростит управление вашим кодом и сделает его более масштабируемым, а также улучшит опыт разработки благодаря автодополнению в современных редакторах и IDE.

5. Начните сейчас

После всего сказанного мой последний совет — начать прямо сейчас. Независимо от того, сколько отличных советов вы используете или насколько хороша архитектура вашего проекта, миграция все равно займет время — просто меньше или больше.

Кроме того, нет никакого способа обойти это. Жестокая правда заключается в том, что в конечном итоге вам придется обновить продукт, чтобы он оставался актуальным и мог предоставлять новые функции. Это, или вам лучше начать переход на другой фреймворк.

Если вы сильно зависите от текущей экосистемы Vue 2, у вас может возникнуть соблазн немного замедлиться, но не стоит. Вместо этого проведите исследование необходимых изменений, подготовьте план обновления, начните работать над совместимыми битами, обратите внимание на сборку совместимости и, возможно, даже подумайте о переключении ваших зависимостей. Если сделать их независимыми от фреймворка, это упростит возможные будущие изменения, а также может привести к поиску лучших альтернатив.

Нижняя линия

Хорошо, так и было. А теперь одно напоминание — не отправляйтесь сразу же в комментарии, чтобы пожаловаться или критиковать что-либо, что вы только что прочитали, только потому, что это не так, как вы думаете. Помните, что это список мнений, и у всех могут быть разные мнения. При этом я приветствую углубленное, ценное и информативное обсуждение.

Я надеюсь, что вы нашли эту статью полезной. Если да, подпишитесь на меня в Twitter, Facebook или через мою рассылку (теперь перезагружено!), чтобы узнать больше о Vue и веб-разработке.

Кроме того, если вы, как и я, являетесь техническим блоггером, рассмотрите возможность использования CodeWrite — бесплатногоинструмента для ведения блога о коде, который прекрасно обрабатывает ваши фрагменты с помощью соответствующих инструментов редактирования и форматирования. с Grammarly и обрабатывает кросс-постинг на Dev.to, Hashnode, Medium и Ghost blogs с потрясающей функцией автоматического заполнения ( я упоминал, что это расширение для браузера?), которое обрабатывает все пограничные случаи за вас (например, преобразование кода из Medium в GitHub Gist или изменение размера больших изображений).

Спасибо за чтение и удачного кодирования!

Этот пост был написан с легкостью, сделан грамматически правильным и размещен здесь в течение 1 клика благодаря CodeWrite с его великолепным редактором, плавной интеграцией Grammarly и публикацией в один клик. Попробуйте бесплатно и используйте код first100, чтобы получить скидку 20 % на подписку (всего 2,40 доллара США в месяц!)