Comments 12
Предположу, что перепись произошла у вас безболезненно и потому много сомнительных утверждений и восторгов.
В чем согласен:
Многие удобные и классные библиотеки действительно не работают на nuxt>2 и это единственное что может удерживать долго на 2 версии. И при переезде надо будет переписывать некоторые компоненты фактически с нуля. Если на такой библиотеке построено ядро, то переписывать придется все. И это единственное фаталити, а больше и не нужно, если мы про Mortal Combat.
Быстрый перебилд Vite, конечно, может играть рояль в девелопменте, но для конечного пользователя это незаметно.
В остальном - у вас большая сова на глобусе и просто хотели переписать и переписали:
Options API vs Compositions API.
Вообще то переписывать не надо. options api прекрасно работает в Vue >=2, причем я придерживаюсь мнения, что Options API дает больше чистоты и понимания, чем мешанина всего в setup.
Мнение что только Compositions API позволяет использовать inheritance а Options API нет, говорит о слабом знании Vue. Renderless components и mixIns существовали изначально, просто про них стали говорить чаще с Vue3.
Новая экосистема Nuxt 3 «заточена» под Pinia.
Может наоборот?
Pinia - логичное упрощение Vuex и проще для менее опытных разработчиков. Однако под капотом, старые мутаторы (mutations) спрятаны в сеттеры и только. Причем на сложных мутациях (сложной смене состояний State) - все равно пишем свой код. а Nuxt/Vue вобще все равно, какой state manager вы используете.
Роутинг и получение данных
...Это требовало не переноса, а полного переосмысления.
Говорю же: хотели переписать и переписали.
По статистике, полное переписывание приложения с нуля происходит через 4-6 лет, и вы прекрасно попали в эту статистику. (Forrester research, full refactoring for business apps after 4–7 years).
Вы решили свои бизнес задачи, молодцы!
Но вот с переездом Nuxt2-Nuxt3-Nuxt4 это связано очень опосредованно. Если бы у вас был талантливый программист на react, angular, svelte или, прости господи, $mal, который успешно помог бы переехать - была бы очень похожая статья просто с другими названиями.
В любом случае @mpanfilov - спасибо за описание положительного опыта переезда. Можете рассказать,, почему остановились на использовании Swiper Slider и пробовали ли Splider?
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
Благодарим за глубокий анализ и ваш взгляд!
Вы правы в том, что технически Options API продолжает работать в Vue 3, а Pinia не является строго обязательной. Однако для нашего конкретного случая — крупного e-commerce монолита со сложной бизнес-логикой — именно Composition API показал себя более эффективным для выделения переиспользуемой логики в composables, что критично для поддержки и масштабирования.
Что касается роутинга — вы точно подметили, что мы действительно хотели переосмыслить архитектуру, а не просто перенести старые решения. Рерайт дал нам эту возможность без ограничений legacy-кода.
По слайдеру: на момент выбора мы не знали о Splider, поэтому продолжили использовать Swiper, теперь есть над чем задуматься:)
Еще раз спасибо за ценные замечания!
Статья отличная, но мало технических деталей. С чем конкретно помог фсд? Как разделяете фичи от виджетов? По моему опыту он вносит только сумятицу, т.к. не четко разделяет некоторые концепции. Сущности - это просто модели данных апи? Или там хранится что-то большее. Какие-то альтернативы рассматривались? В общем требуется ещё статья про фсд отдельно)))
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
С чем конкретно помог FSD?
FSD помог нам победить хаос в структуре проекта.
Раньше была директория components/, и в ней как-то все группировалось по страницам, но в итоге это привело к тому, что код стал иметь сложные перекрестные связи.
Если конкретнее: компоненты разных страниц начинали неконтролируемо импортировать друг друга, бизнес-логика перемешивалась с UI-компонентами, и в результате изменение одного, казалось бы, простого компонента могло неожиданно сломать несколько совершенно разных страниц. Мы называли это "эффектом домино" — непредсказуемое распространение изменений по всему приложению.
Теперь у каждого слоя — своя зона ответственности. Это сделало код предсказуемым, а главное — масштабируемым. Когда в команде несколько разработчиков, строгие правила FSD не дают создать «спагетти-код».
Как разделяете фичи от виджетов?
· Фича — это полноценный пользовательский сценарий, содержащий бизнес-логику. Например, «Оформление заказа» или «Сравнение товаров». Фича использует сущности и виджеты.
· Виджет — это композиция UI-компонентов для переиспользования в рамках одного проекта. Например, «Блок похожих товаров» или «Хлебные крошки». Он не содержит сложной бизнес-логики.
Сущности — это просто модели данных АПИ?
Да,вы угадали. В нашем случае сущности (например, Product, Cart, User) — это в первую очередь типизированные модели данных, которые мы получаем от бэкенда на Symfony. Они определяют «язык» общения между фронтендом и бэкендом.
Насчет отдельной статьи по FSD
Спасибо за предложение!Это отличная идея. Уже планируем подготовить более детальный разбор нашей архитектуры с конкретными примерами из проекта «Аквилон». Следите за обновлениями :)
У вас были какие-то проблемы с производительностью после обновления, докручивали что-то в nuxt.config или всё заработало практически из коробки?
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
Да, некоторые проблемы с производительностью возникли, и в основном они были связаны с нашим первоначальным энтузиазмом по поводу новых возможностей.
Основные моменты, которые пришлось оптимизировать:
Динамические Pinia stores (фабрики) в некоторых сценариях создавали избыточную реактивность
Client-side плагины с watch({ immediate: true }) иногда вызывали каскадные обновления
Местами перегрузили страницы избыточными запросами и вотчерами
Если кратко — мы действительно немного увлеклись новыми возможностями и в некоторых местах "переборщили". В процессе профилирования и тестирования мы выявили эти узкие места и исправили их, оптимизировав количество запросов и реактивных зависимостей.
После этих точечных правок производительность выровнялась до комфортного уровня
А можете показать структуру FSD папок?
Кажется что для этого можно использовать папку Nuxt
~~/layers
https://nuxt.com/docs/4.x/getting-started/layers
Да тут вроде ничего необычного)
app/
assets/
composables/
layouts/
middleware/
nuxt-config/
pages/
plugins/
utils/
entities/
features/
shared/
types/
widgets/а как features/ органиованы?
Это из ридми:
# Слой "Features"
[Описание слоя из документации](https://feature-sliced.design/ru/docs/reference/layers#features)
Данный слой содержит взаймодействия, представляющие реальную ценость для пользователей - какие-либо действия над сущностями.
Действия, которые пользователь может совершать в приложении для взаимодействия с бизнес-сущностями, чтоб достичь ценного для себя результата. Сюда также входят действия, которые приложение выполняет от имени пользователя, чтобы создать для него ценность.
Слайс на этом слое может содержать интерактивные элементы пользовательского интерфейса, внутреннее состояние и запросы к API, которые позволяют выполнять действия, создающие ценность.
Примеры слайсов:
Для социальной сети
Авторизоваться
Создать публикацию
Вступить в группу
Действия от имени пользователя
Автоматически включить тёмную тему
Выполнить вычисления в фоне
Действия на основе User-AgentВ интернет-магазине так:
cart
cities
feedback
order
orders
products
search
security
user
долго переносили?
почему не перенесли сразу на последнюю версию nuxt4?
Переезд с Nuxt 2 на Nuxt 3: почему для крупного интернет-магазина мы выбрали рерайт, а не миграцию