Так зачем откладывать на будущее, когда методология говорить делить здесь и сейчас?)

https://t.me/feature_sliced/1/115327

Ответ от пользователя, который отмечен как эксперт по фсд. На самом деле многое понятно про фсд, если посмотреть основателей =)

Люди могут ошибаться. Здесь я следую документации. Класть в pages это тоже раздувание только на уровне pages. Скажем придет завтра бизнес и скажет хочу другой шаблон с сохранением логики, но старый удалять нельзя. Мы мутим еще один компонент, а логику изолируем в хук/композабл/класс и подключаем в новом компоненте. Копится разное ui представление. Не вижу проблемы в выносе фичей в слой фичей, даже если она одна. В будущем появляется вариативность на уровне сегментов. Вообще странно, что такая вольность допускается. Вот еще бы по бэм писали типа хотите используйте модификатор, а хотите нет, вот мы лично не используем без надобности. Если уж придумали методологию, то надо ее соблюдать, имхо )

Я ничего не имею против фсд как вариант архитектуры. Всё чаще замечаю, что люди читают книжки/статьи и т.п. Но вместо того, чтобы осмысливать услышанное, они берут и используют как Библию. Ровно так же и фсд. Не может какая-то комплексная методология подходить всегда и всем в своей изначальной концепции. Точнее может, если описано подавляющее большинство кейсов, но такого я особо не встречал и всегда приходится так или иначе подстраивать методологию под конкретные нужды. (Что-то отсюда, что-то оттуда).

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

А что вы подразумеваете под бл фичами?

Абстрактно можно взять из интернет магазина. Корзина/Профиль/Заказ/Товар/Рейтинг/Отзывы/Поиск и т.п.

К примеру дефолтный фсд предлагает такую структуру

Когда я её использовал, то немного изменил.

Фичи это про пользовательские действия, они же use cases. С технической стороны это манипуляции над entities и shared. Давайте попробуем на практике с вашим примером. Корзина это страница, которая содержит фичи изменение количества, удаление, применение промокода, т.е у вас будут слайсы cartChangeCountProduct, cartDeleteProduct, cartApplyPromocode. В принципе аналогично можно рассуждать про профиль и заказ. Товар должен дергать функцию добавления себя в корзину из фичи в слайсе cart. Отзывы, рейтинг и поиск это также пользовательские действия. С поиском тут немного по другому будет скорей всего, если рассматривать глобальный поиск и поиск в категории товаров. Ну как-то так )

Я говорю про навигацию в проекте. Дефолтный фсд предлагает структуру, при которой разрабатывая одну бл фичу нужно бегать по всему проекту (папочкам) в поисках нужного entity/feature(fsd)/widget. Когда бл фич становится хотя бы 20, этот процесс становится адом.

Если вам так удобно хорошо ) Мне удобнее мыслить согласно документации

Вы правда используете такую структуру?)

Структура у нас всегда слой - «имя сущности» - слайсы. Есть некоторые оговорки в плане философии entities, но все в рамках fsd. Полет нормальный )

Извращенцы)))) Это если расписать дальше структуру магазина, то путь от CartWidget до CartItem (entity) будет больше пары сотен файлов/папок =)

Для меня привычнее и удобнее поменять слои и слайсы местами, чтобы виджеты/юзкейсы/сущности одной бл были рядом, а не на расстоянии тысяч файлов/папок =)

Скорей всего мы друг друга не понимаем ) Ну, во-первых cart это pages, если нет кейса быстрого просмотра корзины, во вторых entities-> product -> ui-> ProductInCart . Где тут куча директорий и файлов?)

Я скрин прикреплял выше. Там уже путь от CartWidget до CartItem составляет около 30 файлов/папок.

Под путем Я имею ввиду развернуть все папки и посчитать все элементы (папки и файлы) между двумя файлами.

Но не нужно воспринимать скрин как что-то конкретное и осмысленное. Он представляет абстракцию сгенеренную гпт по документации фсд =)

Ну если все развернуть - да, но здесь кому как удобно конечно

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

Лично мне удобно называть вещи своими именами + я подсадил на эти термины наших аналитиков и дизайнера. Это соответствует одному из столпов DDD - ubiquitous language (единый язык) Условно я говорю, что это виджет и люди понимают что это такое. Слайсы не могут и не должны использовать соседей - факт, потому что появится лишняя связь. Профит дается на слое pages, когда мы изолированные фичи/виджеты можем подружить с помощью public api. То есть pages это слой вызывающего кода

Но опять таки, вы про профит фсд, а не про профит изначального деления по widget/feature/entity =)

Ладно, всё равно спасибо за ответ =)

По делению проще навигироваться ) субъективно, понимаю )

https://habr.com/ru/articles/568216/

Небольшую статью по этому поводу нашёл

Почитаю, спасибо )

На одном уровне - в одном сегменте?

Да, на одном уровне, в одном сегменте сегменте. Например, когда есть условный компонент кнопки и переключатель, использующий несколько таких кнопок. И то, и другое – shared компоненты, не несущие бизнес-логики

В shared действительно без разницы. Мы так тоже делаем

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