Комментарии 14
Уже больше года работаю с FSD и могу сказать так, брать и полностью использовать его будет оверинженеринг. Нет смысла условную карточку товара делать частью entity и рендерить внутри кнопки-фичи через рендер пропсы. Это лишние действия которые на выходе дают почти всегда 0 профита.
Модельки стейта я почти всегда храню в entity и не размазываю их по виджетам просто чтобы иметь возможность использовать их на максимальном количестве слоев.
Вообще если даже просто взять и использовать структуру /entities, components, /pages, /shared, хранить в shared дизайн систему, в entities весь стейт и бизнес логику, в components реиспользуемые штуки типа кнопок-фичей, общих виджетов и модалок, а в pages хранить страницы внутри которых могут быть вложенные папки с виджетами то вообще никаких проблем не будет. Сохранится вся гибкость, не будет проблем с цикличными зависмостями ну и вы чётко будете видеть какие вмджеты используются на странице за счёт их вложенности в pages.
Короче говоря размазывание стейта по разным уровням повышает сложность, увеличивает риск цикличных зависимостей и на выходе лично мне особо не даёт профита, а разбиение на компоненты всего на свете тупо увеличивает время на разработку а на выходе профита не даст.
Ну и опять же. С FSD всегда будет вопрос - делать компонент виджетом или фичей? Вы будете сидеть и тупить вместо того чтобы идти и делать задачу. Как итог на выходе у вас папка с фичами будет состоять в основном из кнопок. Тогда почему папка называется features и в чем профит если можно точно так же кнопку сделать частью виджета? Реиспользуемость? Ну ну. Раз в полгода вам понадобится реюзать кнопку из фичи. Стоит ли оно того? Думаю что не стоит.
Ну а то что у вас на проекте были сложности до feature sliced, не означает что проблему нельзя было решить более простым вариантом разбиения ну и более грамотной работой с самой логикой приложения. Очевидно FSD не поможет писать более понятный код. FSD может дать иллюзию того что теперь у вас классная "архитектура", но на деле архитектура это не про папки, да и сложность работы с приложением только увеличится за счёт множества абстракции и постоянной проблемы - куда что класть
Благодарю за ваш опыт!
Я согласна с вами, что FSD можно трансформировать под свои нужды, ведь архитектура проекта - дело командное, как понятнее всем, так и делаем.
У нас в проекте FSD значительно улучшил переиспользование компонентов, так как многие фичи используется хотя бы в двух местах. Безусловно, есть фичи, которые лежат для одного конкретного компонента, зато вся логика и апи вынесены из общего компонента. Иногда, когда дробление не имеет смысла (есть гарантия, что компонент ну точно будет использоваться только в рамках верхнеуровневого), мы оставляем его в папке родителя, но выносим в подпапку, стараясь дать каждому компоненту одно назначение.
Для меня и моей команды FSD показался логичным и аккуратным, хотя немного модифицировать пришлось :) Но архитектура - это дело вкуса, поэтому благодарю за обратное мнение ?
Я добавлю уточнение по поводу переиспользования фичей и дробления, чтобы польза от FSD в моем проекте была немного очевиднее ?
Я недавно стал использовать FSD и у меня возникли вопросы - если в shared слое не хранится бизнес логика, то каким образом работать с типами сущностей? Если их хранить в entities, то, при наличии связанных типов, они будут импортировать друг друга, то есть одна entitie другую, что противоречит философии FSD, а если уносить (как во многих реальных примерах) в shared/api, то получается что мы размещаем в shared бизнес -логику, что тоже вроде бы как не очень правильно.
Мы тоже столкнулись с этой проблемой, поэтому немного модифицировали исходную архитектуру - мы добавили папки sub-entities и sub-features в папки сущностей и фич соотвественно.
Например, у нас есть entity company со своими модельками, одна из которых включает модель talkStep. TalkStep является отдельной сущностью, но существует только в рамках сущности company, поэтому в папке company, кроме стандартных папок апи, моделей и подобного, есть папка sub-entities с сущностью talkStep, что позволяет в компании использовать тип talkStep.
К сожалению, примеров с сущностями, которые имеют один тип вложенности и при этом пересекаются, у нас в проекте нет, возможно, в вашем случае какие-то типы являются подтипами
Мы тоже с этого начали, но если бы сущность TalkStep относилась не только к company, но и к, предположим, users, пришлось бы объединять и их тоже? Получилась бы такая супер - entitie))
Возможно, у нас проблема с архитектурой, но, мне кажется, это частая проблема, не всегда получается "отвязать" сущности друг от друга.
В итоге мы пришли к тому что валим практически все модельки в shared/api...
Мы решили это так: если есть какой-то компонент локальный для сущности слоя, то структура будет, например: entities/parent-component/components/child-component, где child-component, в свою очередь, будет иметь свои папки (utils, store, styles и т.д.). Таким образом получается, что сущности, которые точно не переиспользуемые, не размазываются по приложению.
Да, это не чистый fsd, но и в доке написано, что её может потребоваться модифицировать. Зато это даёт как свободу и переиспользуемость fsd, а также снижает порог входа для новых разработчиков (или старых тех кто с каким-то модулем столкнётся впервые).
Ждём в 3 версии FSD отдельного леера types.
Юзаем FSD в работе около двух лет. Могу сказать, что инструмент достаточно удобный, но главная проблема всегда - чётко разделить сущности от фичей и фичи от виджетов, иногда это не получается от слова совсем. Слишком размытые рамки. В остальном - достаточно удобно, пусть иногда и приходится изобретать велосипед
Всё как обычно - нужно иметь чуйку, когда выделять из общего в частное, а когда обобщать частное в общее (не важно, функции, фронт, бек, инфраструктура, дизайн, бизнес, жизнь..). Также главное не забывать, что - Плоское лучше, чем вложенное.
FSD - это когда авторы опять решили, что Clean Architecture слишком сложно и вообще непонятно, нужно обязательно скрыть всё это структурой папок. Попутно решили, что фронт и бэк вещи не совместимые, слои там разные, логика разная, напишем об этом прямо на главной странице и окончательно превратим идею в монстра Франкенштейна.
В целом, лучше бы был минус один подход.
Для меня главный вопрос к FSD кроме озвученных выше (сущность/виджет/фича), это почему они не придумали названия корневых папок соответствующие уровню. Что бы при стандартной сортировке по алфавиту сразу было видно, что "выше" по архитектуре
Привет, я FSD, чем могу помочь?