createSlice, а не createApi? Если вы про createSlice, то в других менеджерах состояний (например mobx, zustand) обработка запросов к api в сторах делается меньшим количеством кода, кодом ближе к нативному, более простым и более легко переиспользуемым.
Многие так делают. Я же для запросов к api предпочитаю писать обёртку в отдельном слое, чтобы было легче переиспользовать код, не раздувать сторы, менять библиотеки при надобности. А для взаимодействия api и сторов предпочитаю использовать слой контроллеров. https://habr.com/ru/articles/546628/#api
Ну и большинство react-разработчиков сейчас используют библиотеки для кеширования данных запросов без использования стора - react-query (для него и swr можно прикрутить orval для генерации кода запросов к api), swr, rtk query. Но из-за того, что они сделаны через хуки, начинаются сложности, когда данные из кэша нужны в сторах. Да и в сложных кейсах усложняется разработка, т.к. приходится разбираться в разных тонкостях библиотеки. В одних проектах подобные библиотеки стоит использовать, а в других нет.
Альтернатива: для сложного состояния используйте Redux.
Плохой совет. Все менеджеры состояний решают плюс минус одни и те же задачи, но redux и redux toolkit при этом всегда без необходимости сильно усложняют проект.
Если у них 75% разработчиков будут писать 75% кода с помощью ИИ, то через год получат 75% разработчиков, не способных решить ни одной задачи с их алгособесов. Ещё через год-два навыки этих разработчиков скатятся до уровня джуна, а в коде проектов никто не будет ориентироваться, т.к. для этого нужно писать код, а не только читать.
Если собрать всё в одну мысль: фронт становится сложным не из-за стека, а, потому что мы добавляем гибкость раньше, чем она нужна, размываем ответственность и строим инфраструктуру до появления реальной боли.
Из-за стека тоже. Библиотеки и фреймворки тоже создаются с архитектурными ошибками.
В реакте получили разные api для работы с разными видами состояний, хотя некоторые менеджеры состояний позволяют работать одинаково и с локальными и с глобальными состояниями.
Состояния, логика, сайд-эффекты в той же функции, что и разметка. Это усложняет переиспользование частей компонента. Да и код компонентов выглядит запутанно - выполняется нелинейно, при каждом обновлении создаются новые копии переменных и функций, а хуки вроде useCallback, useRef, useMemo уменьшают читабельность.
Библиотеки вроде react-query работают через хуки. Как следствие, когда нужно использовать данные запросов в сторе, обычно эти данные передают через компонент. Получается запутанный поток данных: Бэкенд ➔ useQuery ➔ Компонент ➔ Стор ➔ Компонент, что ещё и приводит к лишнему обновлению компонента.
FSD ради стандартизации и избегания кросс-импортов предлагает применять структуру и правила, неподходящие в большинстве проектов и ситуаций.
Redux, Redux toolkit - чрезмерно усложняют и создают новые проблемы до появления реальной боли, которая решается гораздо проще в приложениях любой сложности.
Добавлю, что с нынешними ценами, особенно на квартиры, 350к для нижнего мидлового грейда выглядит адекватной зарплатой. Но интересно, где сейчас столько платят.
Может просто потому, что каждый проект уникален, и для каждого проекта нужна своя уникальная структура, со своими уникальными ограничениями?
Скорее обычно бывают разные “типы” проектов и разные ситуации, для которых нужны разные решения, а одно стандартное для всех конечно же не подойдёт. Об этом я писал в статье.
Согласен с вами, что вместо FSD лучше учить как “правильно разделить код, зачем вообще его разделять, почему бы не писать все в одном файле”, паттерны, принципы проектирования. Но чтобы научиться это применять, почувствовать надобность, нужны достаточно сложные проекты, а также время, чтобы исследовать, обдумать, попробовать. В реальных же проектах вечно горят сроки, сами проекты в вебе редко бывают сложными, плюс мешает обилие технологий. А проекты делаются жизнеспособными и на плохих хайповых технологиях.
Когда для агентов строгие правила, не удивительно, что результат стабильнее. А вот ревьюить pr-ы, в которых функционал разбросан на 4-5 FSD слоёв, для меня головная боль - много скроллю вверх-вниз, чтобы в голове сложился пазл того, что сделано. LLM-ки таких проблем не испытывают.
eslint-plugin-fsd - с таким не знаком. Вы правильно написали? Слышал про steiger и линтеры, которые были до него. Агентов мы ещё не используем. Нужные нам правила описали с помощью eslint-plugin-boundaries.
Было бы интересно взглянуть на файлогенератор, который вы используете. Не скинете ссылку на него, примеры его настроек, результат его работы, если есть в открытом доступе? Не планируете написать об этом статью?
Мне наиболее удобный, понятный и масштабируемый результат давал подход, называемый folder-by-feature, feature folders, модульный (если не ошибаюсь).Но я встречал только описание общего принципа этого подхода - "группировка по фичам" - без подробных деталей.
Если не натыкать палок в колеса в common, то оно в короткие достаточно сроки превращается в свалку "не знал куда положить, кинул в туда" и в реальных проектах это наблюдалось далеко не 1 раз.
Мне кажется из-за неприятного опыта в прошлом вы решили пойти очень сомнительным путём. Если модули выносить из common в modules, то слой modules может разрастить и стать запутанным, т.к. многие модули будут связаны. Если проект не на пару недель, то в common лучше сразу группировать утилиты по назначению, а также прочие файлы группировать в модули по назначению. В FSD так делается в shared/lib. Как по мне, лучше порефачить свалку, написать правила для линтеров для ограничения импортов, чем усложнять проект, создавая обходные пути, чтобы воспользоваться функционалом из слоя выше.
Выглядит лучше, чем FSD. Понравилось, что статья очень хорошо структурирована.
Не планируете как-то ещё продвигать методологию? Хотелось бы поскорее похоронить нынешний стандарт (FSD), который я считаю одним из худших подходов к организации файловой структуры проекта.
Касательно слоя Modules – радует, что наконец-то начинают возвращаться к тому, что было в прошлом - одному бизнес-слою вместо размазывания связанной бизнес-логики по 4-ём FSD-шным.
Вопрос насчёт папок modules, ui, api в этом слое – я правильно понимаю, что группирование файлов в модулях по подобным папкам не обязательно? На мой взгляд, в большинстве проектов это лишь удвоит вложенность, не принеся пользы. В проектах, в которых я участвовал и в которых был аналог слоя Modules, мы не заводили подобные папки (за исключением вложенной папки modules – аналогичные редко заводили, если скапливалось много вложенных папок-подмодулей) и проблем не возникло.
Я за последние пару лет побывал на паре проектов с Redux Toolkit (в одном из них использовали Redux Toolkit Query), а лет 5 назад был на проекте с Redux. В одном проекте с Redux Toolkit стали переходить на Mobx, а в другом на Zustand. В обоих случаях мне говорили, что код стал сильно понятней и стало проще разрабатывать.
В 2025 году Redux Toolkit не имеет никакого бойлерплейта и прост, как пять копеек.
Redux в 2018 году и Redux Toolkit в 2025 это две большие разницы.
Разница большая, но особо лучше не стало. Одни недостатки сменились на другие. Гибкость низкая. Стал сложнее. Все ещё на любой чих приходиться писать много кода в избыточном количестве файлов. По-прежнему вместо вызова методов диспатчат экшены. Для типовых задач используется своеобразное api, далекое от нативного.
Проблемно и неочевидно вынести дублирующиеся в разных слайсах редьюсеры, части стейта. Я как-то спросил в большом корпоративном фронтенд чате, как это лучше сделать. Получил с десяток рекомендаций сменить стейт менеджер) На эту тему пишут целые статье вроде этой: https://habr.com/ru/articles/771660/ А в официальной документации предлагают такое: https://redux-toolkit.js.org/usage/usage-with-typescript#wrapping-createslice This can be done with createSlice as well, but due to the complexity of the types for createSlice, you have to use the SliceCaseReducers and ValidateSliceCaseReducers types in a very specific way. А ведь в слайсах могут понадобиться не только стейт и редьюсеры, но и селекторы с extraReducers.
Добавлю, что когда для записи в локальный и глобальный стейт используется сильно отличающийся код, это ненужное усложнение. В некоторых стейт менеджерах можно использовать одно и то же api для работы с обоими видами состояний.
Автору статьи и тем, кто всё еще пишет на Redux Toolkit рекомендую для начала попробовать Zustand. Это популярный редаксо-подобный более простой стейт менеджер с меньшим количеством бойлерплейта. После него Redux Toolkit большинству перестает казаться хорошим решением) Но Zustand не избавляет от бойлерплейта селекторов в компонентах. Чтобы избавиться еще и от этого бойлерплейта можно воспользоваться react-tracked. Получиться ближе к более читаемому и гибкому коду, получаемому при использовании таких стейт менеджеров как mobx, valtio. Ну и если нужен аналог Redux Toolkit Query, то есть React-Query.
Низкая скорость разработки на старте. React не фреймворк, а скорее конструктор фреймворков. Надо подключить и настроить с десяток-другой библиотек, написать обертки для компонентов форм, чтобы упростить и ускорить работу с библиотекой вроде React Hook Form.
Порог вхождения в экосистему React стал довольно большим.
Вместо того, чтобы использовать общее api для глобального и локального состояния, у нас теперь для каждого вида состояний появилось свое api - useState, менеджер состояний или контекст, библиотека для форм, библиотека для кэша с бэка.
Хуки добавляют больше проблем, чем решают. Переиспользовать логику можно и на объектах с меньшей болью. Наследование для этого не нужно. Сами классы не плохи, а вот реализация компонентов на классах плоховата. Вместо привязки переменных к this в компоненте и привязки функций к this через auto bind или стрелочные функции теперь на каждый вызов компонента создаются новые функции и значения. Оборачивание их в хуки делает код компонента менее читаемым. А если забыть обернуть, можно получить баги или проблемы с производительностью. useMemo нужно использовать с умом, т.к. излишняя мемоизация тоже может приводит к снижению производительности. Еще надо не забывать, что передача неизменившихся пропсов, обернутых в useMemo и useCallback или useRef, без обертки компонента в React.Memo не избавит от лишних рендеров. useEffect теперь практически антипаттерн, но об этом уже написано в статье.
Для гибкости и чистоты кода логику стоит отделять от отображения. В классовых компонентах этого не делалось, но там хотя бы jsx писался в отдельной функции в компоненте. Сейчас же в одной функции пишется и логика и jsx.
Лично мне нравиться включать и отключать дополнительную переиспользуемую логику компонента через директивы, но их нет в React-те. Вместо этого есть хуки, которые обычно намертво прибиты к компонентам.
Такие вещи как React Query сделаны на хуках. Получился не один, а два источника данных (стор и кэш), которые зачастую нужно объединять. Теперь обмен данными между стором и api обычно делают не напрямую, а через view слой. Чаще всего через useEffect, добавляя лишние обновления компонента и запутывая код. React Query хуки обычно вызывают не в одном месте, а в каждом компоненте, где требуются данные с бека, тем самым нарушая консистентность и теряя прозрачность взаимодействия фронта с беком.
Попытаюсь представить полный отказ от SOLID. Получаем десятки и сотни хуков в каждом компоненте. В каждый компонент добавляем switch для обработки всех компонентов, которые он получает через children. Для каждой кнопки с отличным действием на onClick делаем новый компонент-кнопку, т.к. каждый onClick работает не с абстрактными функциями, а только с одной конкретной функцией.
Многие почему-то считают, что сущность - это класс.
В 2-х моих проектах сущностью было то, для чего выделен url по rest с набором методов. Для отображения каждой такой сущности были свои страницы. Часть сущностей были вложенными в другие.
Я общался в чате на эту тему и мне сторожилы fsd предупредили, что не надо дробить, ради дробления. Всё должно быть компактно по возможности.
Когда я спрашивал в чате, мне наоборот порекомендовали сразу дробить, чтобы потом не рефакторить, с чем я был не согласен)
Не могли бы вы скинуть ссылку на эту дискуссию? Будет аргументом для объединения лишних слоев.
"Большинство используют общепринятые сегменты, разделяя функционал по типу, а не по связанному назначению."
Это тоже не проблема fsd, а его прочтения. Человек приходит со своими тараканами в голове и пытается делать что-то новое по-старому и прогресса не получается.
Что тут имеете ввиду? Что разработчики не правильно делят на сегменты или что я пытаюсь делать по-привычному? У нас плюс-минус стандартные сегменты и большая их часть написана коллегами, да и я сначала попробовал по-новому и пока продолжаю. Чем больше работаю с сегментами, тем больше ощущаю, что по-старому было лучше. В вашем примере я тоже вижу стандартные папки-сегменты, имена которых мне не говорят, что за функционал внутри них и с каким функционал соседних сегментов он связаны. Если слайс станет большим и в нем будет не 1-2 файла в каждом сегменте, а по 5-10, то сомневаюсь, что будет так же легко разобраться, что с чем связано.
Поэтому я склонен считать, что эти беды не от fsd, а от непонимания его.
Учитывая, что даже у сеньоров (причем у большинства) разное понимание fsd и непонимание каких-то его моментов, то тут беда в том, что или он сложноват для понимания, или документация не достаточно полная и не достаточно понятно его описывает.
createSlice, а не createApi? Если вы про createSlice, то в других менеджерах состояний (например mobx, zustand) обработка запросов к api в сторах делается меньшим количеством кода, кодом ближе к нативному, более простым и более легко переиспользуемым.
Многие так делают. Я же для запросов к api предпочитаю писать обёртку в отдельном слое, чтобы было легче переиспользовать код, не раздувать сторы, менять библиотеки при надобности. А для взаимодействия api и сторов предпочитаю использовать слой контроллеров. https://habr.com/ru/articles/546628/#api
https://habr.com/ru/articles/546628/#controller
Ну и большинство react-разработчиков сейчас используют библиотеки для кеширования данных запросов без использования стора - react-query (для него и swr можно прикрутить orval для генерации кода запросов к api), swr, rtk query. Но из-за того, что они сделаны через хуки, начинаются сложности, когда данные из кэша нужны в сторах. Да и в сложных кейсах усложняется разработка, т.к. приходится разбираться в разных тонкостях библиотеки. В одних проектах подобные библиотеки стоит использовать, а в других нет.
Плохой совет. Все менеджеры состояний решают плюс минус одни и те же задачи, но redux и redux toolkit при этом всегда без необходимости сильно усложняют проект.
Если у них 75% разработчиков будут писать 75% кода с помощью ИИ, то через год получат 75% разработчиков, не способных решить ни одной задачи с их алгособесов. Ещё через год-два навыки этих разработчиков скатятся до уровня джуна, а в коде проектов никто не будет ориентироваться, т.к. для этого нужно писать код, а не только читать.
Из-за стека тоже. Библиотеки и фреймворки тоже создаются с архитектурными ошибками.
В реакте получили разные api для работы с разными видами состояний, хотя некоторые менеджеры состояний позволяют работать одинаково и с локальными и с глобальными состояниями.
Состояния, логика, сайд-эффекты в той же функции, что и разметка. Это усложняет переиспользование частей компонента. Да и код компонентов выглядит запутанно - выполняется нелинейно, при каждом обновлении создаются новые копии переменных и функций, а хуки вроде useCallback, useRef, useMemo уменьшают читабельность.
Библиотеки вроде react-query работают через хуки. Как следствие, когда нужно использовать данные запросов в сторе, обычно эти данные передают через компонент. Получается запутанный поток данных: Бэкенд ➔ useQuery ➔ Компонент ➔ Стор ➔ Компонент, что ещё и приводит к лишнему обновлению компонента.
FSD ради стандартизации и избегания кросс-импортов предлагает применять структуру и правила, неподходящие в большинстве проектов и ситуаций.
Redux, Redux toolkit - чрезмерно усложняют и создают новые проблемы до появления реальной боли, которая решается гораздо проще в приложениях любой сложности.
Добавлю, что с нынешними ценами, особенно на квартиры, 350к для нижнего мидлового грейда выглядит адекватной зарплатой. Но интересно, где сейчас столько платят.
В каком стеке технологий столько платят? Компанию наверное не назовёте?)
Насколько я вижу, последние пару лет потолок зарплаты сеньоров - 400-450. Больше мало кто получает и в основном в новых специальностях.
Спасибо за интересную, полезную и крутую статью!
В такую большую статью было бы здорово добавить ссылки-якоря на главы для удобства навигации.
Скорее обычно бывают разные “типы” проектов и разные ситуации, для которых нужны разные решения, а одно стандартное для всех конечно же не подойдёт. Об этом я писал в статье.
Согласен с вами, что вместо FSD лучше учить как “правильно разделить код, зачем вообще его разделять, почему бы не писать все в одном файле”, паттерны, принципы проектирования. Но чтобы научиться это применять, почувствовать надобность, нужны достаточно сложные проекты, а также время, чтобы исследовать, обдумать, попробовать. В реальных же проектах вечно горят сроки, сами проекты в вебе редко бывают сложными, плюс мешает обилие технологий. А проекты делаются жизнеспособными и на плохих хайповых технологиях.
Когда для агентов строгие правила, не удивительно, что результат стабильнее. А вот ревьюить pr-ы, в которых функционал разбросан на 4-5 FSD слоёв, для меня головная боль - много скроллю вверх-вниз, чтобы в голове сложился пазл того, что сделано. LLM-ки таких проблем не испытывают.
eslint-plugin-fsd - с таким не знаком. Вы правильно написали? Слышал про steiger и линтеры, которые были до него. Агентов мы ещё не используем. Нужные нам правила описали с помощью eslint-plugin-boundaries.
Подумаю над добавлением объяснения. Показалось это избыточным, т.к. во фронтенде это довольно известная методология.
Спасибо!
Было бы интересно взглянуть на файлогенератор, который вы используете. Не скинете ссылку на него, примеры его настроек, результат его работы, если есть в открытом доступе? Не планируете написать об этом статью?
Сейчас только начинают делать шаги в сторону создания описания более простых и понятных концепций размещения по папкам.
Например:
https://ed.evocomm.space/guide/
https://habr.com/ru/companies/sportmaster_lab/articles/972410/
Мне наиболее удобный, понятный и масштабируемый результат давал подход, называемый folder-by-feature, feature folders, модульный (если не ошибаюсь).Но я встречал только описание общего принципа этого подхода - "группировка по фичам" - без подробных деталей.
Мне кажется из-за неприятного опыта в прошлом вы решили пойти очень сомнительным путём. Если модули выносить из common в modules, то слой modules может разрастить и стать запутанным, т.к. многие модули будут связаны. Если проект не на пару недель, то в common лучше сразу группировать утилиты по назначению, а также прочие файлы группировать в модули по назначению. В FSD так делается в shared/lib.
Как по мне, лучше порефачить свалку, написать правила для линтеров для ограничения импортов, чем усложнять проект, создавая обходные пути, чтобы воспользоваться функционалом из слоя выше.
Выглядит лучше, чем FSD. Понравилось, что статья очень хорошо структурирована.
Не планируете как-то ещё продвигать методологию? Хотелось бы поскорее похоронить нынешний стандарт (FSD), который я считаю одним из худших подходов к организации файловой структуры проекта.
Касательно слоя Modules – радует, что наконец-то начинают возвращаться к тому, что было в прошлом - одному бизнес-слою вместо размазывания связанной бизнес-логики по 4-ём FSD-шным.
Вопрос насчёт папок modules, ui, api в этом слое – я правильно понимаю, что группирование файлов в модулях по подобным папкам не обязательно? На мой взгляд, в большинстве проектов это лишь удвоит вложенность, не принеся пользы. В проектах, в которых я участвовал и в которых был аналог слоя Modules, мы не заводили подобные папки (за исключением вложенной папки modules – аналогичные редко заводили, если скапливалось много вложенных папок-подмодулей) и проблем не возникло.
Я за последние пару лет побывал на паре проектов с Redux Toolkit (в одном из них использовали Redux Toolkit Query), а лет 5 назад был на проекте с Redux. В одном проекте с Redux Toolkit стали переходить на Mobx, а в другом на Zustand. В обоих случаях мне говорили, что код стал сильно понятней и стало проще разрабатывать.
Разница большая, но особо лучше не стало. Одни недостатки сменились на другие. Гибкость низкая. Стал сложнее. Все ещё на любой чих приходиться писать много кода в избыточном количестве файлов. По-прежнему вместо вызова методов диспатчат экшены. Для типовых задач используется своеобразное api, далекое от нативного.
Проблемно и неочевидно вынести дублирующиеся в разных слайсах редьюсеры, части стейта. Я как-то спросил в большом корпоративном фронтенд чате, как это лучше сделать. Получил с десяток рекомендаций сменить стейт менеджер)
На эту тему пишут целые статье вроде этой: https://habr.com/ru/articles/771660/
А в официальной документации предлагают такое:
https://redux-toolkit.js.org/usage/usage-with-typescript#wrapping-createslice
This can be done with createSlice as well, but due to the complexity of the types for createSlice, you have to use the SliceCaseReducers and ValidateSliceCaseReducers types in a very specific way.
А ведь в слайсах могут понадобиться не только стейт и редьюсеры, но и селекторы с extraReducers.
Добавлю, что когда для записи в локальный и глобальный стейт используется сильно отличающийся код, это ненужное усложнение. В некоторых стейт менеджерах можно использовать одно и то же api для работы с обоими видами состояний.
Автору статьи и тем, кто всё еще пишет на Redux Toolkit рекомендую для начала попробовать Zustand. Это популярный редаксо-подобный более простой стейт менеджер с меньшим количеством бойлерплейта. После него Redux Toolkit большинству перестает казаться хорошим решением) Но Zustand не избавляет от бойлерплейта селекторов в компонентах. Чтобы избавиться еще и от этого бойлерплейта можно воспользоваться react-tracked. Получиться ближе к более читаемому и гибкому коду, получаемому при использовании таких стейт менеджеров как mobx, valtio. Ну и если нужен аналог Redux Toolkit Query, то есть React-Query.
Добавлю про недостатки:
Низкая скорость разработки на старте. React не фреймворк, а скорее конструктор фреймворков. Надо подключить и настроить с десяток-другой библиотек, написать обертки для компонентов форм, чтобы упростить и ускорить работу с библиотекой вроде React Hook Form.
Порог вхождения в экосистему React стал довольно большим.
Вместо того, чтобы использовать общее api для глобального и локального состояния, у нас теперь для каждого вида состояний появилось свое api - useState, менеджер состояний или контекст, библиотека для форм, библиотека для кэша с бэка.
Хуки добавляют больше проблем, чем решают. Переиспользовать логику можно и на объектах с меньшей болью. Наследование для этого не нужно. Сами классы не плохи, а вот реализация компонентов на классах плоховата.
Вместо привязки переменных к this в компоненте и привязки функций к this через auto bind или стрелочные функции теперь на каждый вызов компонента создаются новые функции и значения. Оборачивание их в хуки делает код компонента менее читаемым. А если забыть обернуть, можно получить баги или проблемы с производительностью. useMemo нужно использовать с умом, т.к. излишняя мемоизация тоже может приводит к снижению производительности. Еще надо не забывать, что передача неизменившихся пропсов, обернутых в useMemo и useCallback или useRef, без обертки компонента в React.Memo не избавит от лишних рендеров.
useEffect теперь практически антипаттерн, но об этом уже написано в статье.
Для гибкости и чистоты кода логику стоит отделять от отображения. В классовых компонентах этого не делалось, но там хотя бы jsx писался в отдельной функции в компоненте. Сейчас же в одной функции пишется и логика и jsx.
Лично мне нравиться включать и отключать дополнительную переиспользуемую логику компонента через директивы, но их нет в React-те.
Вместо этого есть хуки, которые обычно намертво прибиты к компонентам.
Такие вещи как React Query сделаны на хуках. Получился не один, а два источника данных (стор и кэш), которые зачастую нужно объединять. Теперь обмен данными между стором и api обычно делают не напрямую, а через view слой. Чаще всего через useEffect, добавляя лишние обновления компонента и запутывая код. React Query хуки обычно вызывают не в одном месте, а в каждом компоненте, где требуются данные с бека, тем самым нарушая консистентность и теряя прозрачность взаимодействия фронта с беком.
Если до этого команда не писала на FSD, то видимо вы решили окончательно угробить проект)
Попытаюсь представить полный отказ от SOLID. Получаем десятки и сотни хуков в каждом компоненте. В каждый компонент добавляем switch для обработки всех компонентов, которые он получает через children. Для каждой кнопки с отличным действием на onClick делаем новый компонент-кнопку, т.к. каждый onClick работает не с абстрактными функциями, а только с одной конкретной функцией.
В 2-х моих проектах сущностью было то, для чего выделен url по rest с набором методов. Для отображения каждой такой сущности были свои страницы. Часть сущностей были вложенными в другие.
Когда я спрашивал в чате, мне наоборот порекомендовали сразу дробить, чтобы потом не рефакторить, с чем я был не согласен)
Не могли бы вы скинуть ссылку на эту дискуссию? Будет аргументом для объединения лишних слоев.
Что тут имеете ввиду? Что разработчики не правильно делят на сегменты или что я пытаюсь делать по-привычному? У нас плюс-минус стандартные сегменты и большая их часть написана коллегами, да и я сначала попробовал по-новому и пока продолжаю. Чем больше работаю с сегментами, тем больше ощущаю, что по-старому было лучше. В вашем примере я тоже вижу стандартные папки-сегменты, имена которых мне не говорят, что за функционал внутри них и с каким функционал соседних сегментов он связаны. Если слайс станет большим и в нем будет не 1-2 файла в каждом сегменте, а по 5-10, то сомневаюсь, что будет так же легко разобраться, что с чем связано.
Учитывая, что даже у сеньоров (причем у большинства) разное понимание fsd и непонимание каких-то его моментов, то тут беда в том, что или он сложноват для понимания, или документация не достаточно полная и не достаточно понятно его описывает.