Здравствуйте, я лидировал направление фронтенда при разработке проекта.
С чем конкретно помог FSD? FSD помог нам победить хаос в структуре проекта.
Раньше была директория components/, и в ней как-то все группировалось по страницам, но в итоге это привело к тому, что код стал иметь сложные перекрестные связи.
Если конкретнее: компоненты разных страниц начинали неконтролируемо импортировать друг друга, бизнес-логика перемешивалась с UI-компонентами, и в результате изменение одного, казалось бы, простого компонента могло неожиданно сломать несколько совершенно разных страниц. Мы называли это "эффектом домино" — непредсказуемое распространение изменений по всему приложению.
Теперь у каждого слоя — своя зона ответственности. Это сделало код предсказуемым, а главное — масштабируемым. Когда в команде несколько разработчиков, строгие правила FSD не дают создать «спагетти-код».
Как разделяете фичи от виджетов?
· Фича — это полноценный пользовательский сценарий, содержащий бизнес-логику. Например, «Оформление заказа» или «Сравнение товаров». Фича использует сущности и виджеты. · Виджет — это композиция UI-компонентов для переиспользования в рамках одного проекта. Например, «Блок похожих товаров» или «Хлебные крошки». Он не содержит сложной бизнес-логики.
Сущности — это просто модели данных АПИ? Да,вы угадали. В нашем случае сущности (например, Product, Cart, User) — это в первую очередь типизированные модели данных, которые мы получаем от бэкенда на Symfony. Они определяют «язык» общения между фронтендом и бэкендом.
Насчет отдельной статьи по FSD Спасибо за предложение!Это отличная идея. Уже планируем подготовить более детальный разбор нашей архитектуры с конкретными примерами из проекта «Аквилон». Следите за обновлениями :)
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
Да, некоторые проблемы с производительностью возникли, и в основном они были связаны с нашим первоначальным энтузиазмом по поводу новых возможностей.
Основные моменты, которые пришлось оптимизировать:
Динамические Pinia stores (фабрики) в некоторых сценариях создавали избыточную реактивность
Client-side плагины с watch({ immediate: true }) иногда вызывали каскадные обновления
Местами перегрузили страницы избыточными запросами и вотчерами
Если кратко — мы действительно немного увлеклись новыми возможностями и в некоторых местах "переборщили". В процессе профилирования и тестирования мы выявили эти узкие места и исправили их, оптимизировав количество запросов и реактивных зависимостей.
После этих точечных правок производительность выровнялась до комфортного уровня
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
Благодарим за глубокий анализ и ваш взгляд!
Вы правы в том, что технически Options API продолжает работать в Vue 3, а Pinia не является строго обязательной. Однако для нашего конкретного случая — крупного e-commerce монолита со сложной бизнес-логикой — именно Composition API показал себя более эффективным для выделения переиспользуемой логики в composables, что критично для поддержки и масштабирования.
Что касается роутинга — вы точно подметили, что мы действительно хотели переосмыслить архитектуру, а не просто перенести старые решения. Рерайт дал нам эту возможность без ограничений legacy-кода.
По слайдеру: на момент выбора мы не знали о Splider, поэтому продолжили использовать Swiper, теперь есть над чем задуматься:)
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
С чем конкретно помог FSD?
FSD помог нам победить хаос в структуре проекта.
Раньше была директория
components/, и в ней как-то все группировалось по страницам, но в итоге это привело к тому, что код стал иметь сложные перекрестные связи.Если конкретнее: компоненты разных страниц начинали неконтролируемо импортировать друг друга, бизнес-логика перемешивалась с UI-компонентами, и в результате изменение одного, казалось бы, простого компонента могло неожиданно сломать несколько совершенно разных страниц. Мы называли это "эффектом домино" — непредсказуемое распространение изменений по всему приложению.
Теперь у каждого слоя — своя зона ответственности. Это сделало код предсказуемым, а главное — масштабируемым. Когда в команде несколько разработчиков, строгие правила FSD не дают создать «спагетти-код».
Как разделяете фичи от виджетов?
· Фича — это полноценный пользовательский сценарий, содержащий бизнес-логику. Например, «Оформление заказа» или «Сравнение товаров». Фича использует сущности и виджеты.
· Виджет — это композиция UI-компонентов для переиспользования в рамках одного проекта. Например, «Блок похожих товаров» или «Хлебные крошки». Он не содержит сложной бизнес-логики.
Сущности — это просто модели данных АПИ?
Да,вы угадали. В нашем случае сущности (например, Product, Cart, User) — это в первую очередь типизированные модели данных, которые мы получаем от бэкенда на Symfony. Они определяют «язык» общения между фронтендом и бэкендом.
Насчет отдельной статьи по FSD
Спасибо за предложение!Это отличная идея. Уже планируем подготовить более детальный разбор нашей архитектуры с конкретными примерами из проекта «Аквилон». Следите за обновлениями :)
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
Да, некоторые проблемы с производительностью возникли, и в основном они были связаны с нашим первоначальным энтузиазмом по поводу новых возможностей.
Основные моменты, которые пришлось оптимизировать:
Динамические Pinia stores (фабрики) в некоторых сценариях создавали избыточную реактивность
Client-side плагины с watch({ immediate: true }) иногда вызывали каскадные обновления
Местами перегрузили страницы избыточными запросами и вотчерами
Если кратко — мы действительно немного увлеклись новыми возможностями и в некоторых местах "переборщили". В процессе профилирования и тестирования мы выявили эти узкие места и исправили их, оптимизировав количество запросов и реактивных зависимостей.
После этих точечных правок производительность выровнялась до комфортного уровня
Здравствуйте, я лидировал направление фронтенда при разработке проекта.
Благодарим за глубокий анализ и ваш взгляд!
Вы правы в том, что технически Options API продолжает работать в Vue 3, а Pinia не является строго обязательной. Однако для нашего конкретного случая — крупного e-commerce монолита со сложной бизнес-логикой — именно Composition API показал себя более эффективным для выделения переиспользуемой логики в composables, что критично для поддержки и масштабирования.
Что касается роутинга — вы точно подметили, что мы действительно хотели переосмыслить архитектуру, а не просто перенести старые решения. Рерайт дал нам эту возможность без ограничений legacy-кода.
По слайдеру: на момент выбора мы не знали о Splider, поэтому продолжили использовать Swiper, теперь есть над чем задуматься:)
Еще раз спасибо за ценные замечания!