Структура Vue проекта

[cmyser]

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

Но это есть только лишь в одном фрейморке который нельзя называть...

[Pnym]

Vue пытается усидеть на всех стульях одновременно))

[cmyser]

Это плохое решение

Все люди пишут код и архитектуру по разному

[davidaganov]

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

[cmyser]

Вот это и плохо что у вас по разному

Мне вот очень нравится как в $mol придумали

Там название класса строго равно пути в файловой системе

Допустим прилетает инц с прода

Сломался компонент

$mol_bigtechcompany_srm_slider

И я сразу понимаю что он лежит по пути mol/bigtechcompany/srm/slider/ и в этой папке три файла

slider.view.ts ( логика )

slider.view.tree ( декларативное описание компонента без привязки к html )

slider.view.css.ts ( типизированные стили каскадные )

[davidaganov]

ну, не знаю в чём проблема, потому что у вью/накста хорошие логи и я ни разу не сталкивался чтобы во время ошибки в каком-то файле мне логи не показали в каком именно проблема. единственное к чему я отношусь скептически - автоимпорт в Nuxt. там да, не всегда понятно откуда берутся те или иные композаблы, компоненты и т.д, могут как из внешней либы прилетать, так и самописные. но в плане структуры гибкость куда важнее, условно, легкий проект я просто сделаю с плоской структурой, а большой продукт - с иной структурой, которая лучше подойдет проекту, а фичи vue будут работать адекватно и с первой и со второй

[cmyser]

Логи на проде ? Не знал что есть

Что значит архитектура лучше подходит проекту ? В $mol вся разница будет в количестве компонент, но получится даже гибче и переиспользуемее ( я могу использовать компоненты из других чужих репозиториев в своих проектах по имени, при этом менять не только стили, но и логику и то что компонент рендерит )

Вообще по расположению файлов есть отличная аналитика

https://mol.hyoo.ru/#!section=docs/=nekayw_7ibj8f

[davidaganov]

для логирования на проде есть специальные инструменты, это всё не костыли и, в целом, не является какой-то проблемой. я ещё не видел ни одной архитектуры которая себя одинаково показывала бы хорошо и на маленьких масштабах (2-3 страницы, 20-30 компонентов) и на больших (например, 20-50 страниц, 200-500 компонентов). плоской архитектуры будет недостаточно для большого сайта, а какой-нибудь FSD будет слишком чрезмерен для того чтобы 20 компонентов распихивать по куче папок. смотрел как работать с $mol, его архитектуру и, честно говоря, никогда бы не взял это на простенький сайт, выглядит до жути громоздко, а для крупного проекта в $mol критически много чего не хватает для удобной и быстрой разработки. да, может там больше "свободы" и меньше магии, чем в том же Vue, но мне этот подход чужд. на счёт компонентов - да, на бумаге прикольная фича, но уже давно появились какие-нибудь shadcn которые так же легко редактируются и переписываются под свои нужды в своём проекте, что закрывает почти все потребности

[cmyser]

я ещё не видел ни одной архитектуры которая себя одинаково показывала бы хорошо и на маленьких масштабах

вот как раз в моле оно одинаково хорошо и для того и для другого

никогда бы не взял это на простенький сайт, выглядит до жути громоздко,

минимальный компонент можно в 1 строку записать
для сайта нужен файл входной index.html
это же немного совсем, тут скорее непривычно

а для крупного проекта в $mol критически много чего не хватает для удобной и быстрой разработки. 

например ? мне хватает ;) например для такого https://bot.giper.dev/ ( тут экосистема продуктов )

на счёт компонентов - да, на бумаге прикольная фича, но уже давно появились какие-нибудь shadcn которые так же легко редактируются и переписываются под свои нужды в своём проекте, что закрывает почти все потребности

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

ну и сравнение

о них интересно написано тут
https://habr.com/ru/articles/341146/
и тут https://mol.hyoo.ru/#!section=docs/=cx1tyu_aduyqj

[adobry96]

Отличная статья спасибо!

Лично я пробовал реализовать разные подохды. Но честно говоря ничего не понравилось)

В итоге на проектах всегда пишу что-то среднее между модулями и FSD.

Я full-stack разработчик и мыслю немного по другому - контрактами.

У нас должен быть контракт того что возращает нам backend (response) и мы маппим это в данные с которыми работаем внутри нашего приложения, а также данные которые мы отправляем на backend (request). Т.е. для одной сущности я часто делаю 3 класса Response, Request, Model, к ним добавляется маппер для маппинга всего этого)

А компоненты лично я распределяю так: переиспользуемые глобальные это core - ядро системы, в папке Buttons кнопки и т.д.

Если же компоненты уже страничные то в папке components по названию страницв или по содержанию логическому, к примеру Cards или Products.

Ну и конечно папки pages, stores, plugins, middleware и т.д.

Еще мне нравится в nuxt layouts но это уже другое конечно)

P.s. выше написал лично свою точку зрения)