Вы про тип Props? В подавляющем большинстве случаев типы у каждого компонента свои.
Есть несколько случаев, компонентов-модификаторов, которые переиспользуют тип от основного блока (это если говорить терминами БЭМ) но они все в пределах одного слайса, поэтому проблем с импортами нет.
В остальном у каждого компонента свои типы. Мне кажется это вполне оправдано.
Во первых, спасибо за такой развернутый комментарий! Спасибо, что делитесь опытом!
Возможно это странно, но по моему опыту работы я сталкивался с большинством описанных трудностей на проектах без fsd - неоднозначность, куда разместить общую для сущностей логику, как содержать связные бизнесс-сущности, особенно если у них есть свои самостоятельные разделы. Свалка в lib, когнитивная нагрузка и тд.
Поэтому я склонен считать, что эти беды не от fsd, а от непонимания его.
Особенно, если говорить про связные бизнесс-сущности. Многие почему-то считают, что сущность - это класс. Я в корне не согласен. Если у вас есть механизм геолокаций, то там будет с дюжину классов - страна, город, индекс, улица, мкрн, дом, подъезд, этаж, квартира. Вы ж не станете это делить на 10 сущностей и потом пытаться объединить через надуманные механизмы?.. это бойлерплейт чистой воды.. Нет, сделайте одну сущность geolocation и радуйтесь. И то если это доменная сущность. А коли нет, то место ей в shared)))
Если у вас проект прям сильно крутится вокруг одной большой сущности, Которая связана сразу со всем в системе (а я встречал такие проекты) ну тогда может быть fsd тут не уместен. Это ж не панацея всё таки.
По части destructive decoupling - опять некорректное прочтение методологии. Я общался в чате на эту тему и мне сторожилы fsd предупредили, что не надо дробить, ради дробления. Всё должно быть компактно по возможности.
Большинство используют общепринятые сегменты, разделяя функционал по типу, а не по связанному назначению.
Это тоже не проблема fsd, а его прочтения. Человек приходит со своими тараканами в голове и пытается делать что-то новое по-старому и прогресса не получается. У меня то же самое произошло в процессе рефакторинга, слава богу мозги вправили и я быстренько всё переделал.
зачастую сложно понять, в какой слой поместить тот или иной файл.
Забавно, но у меня эта проблема возникала всегда на предыдущих проектах, но не в fsd. В fsd я как-то разобрался за пару дней и всё наоборот стало предельно ясно. В моём случае fsd наоборот помог решить данную дилемму.
Мое мнение, что каждой технологии - своё время. А ещё мне кажется, что даже если и выйдет что-то нативное на JS, то без опыта реакта и всего, что его окружает, это было бы просто невозможно)) как минимум он задал вектор, куда стоит развивать отрасль.
Про переиспользование функционала можно сделать монорепу с совместными packages
Были мысли и про монорепы и про субмодули и даже про пакет в npm.. выбрали путь объединения проектов. Тем более, что это вполне было логично и с других течек зрения.
В плане NextJS спорить не буду. Мне лично он тоже не нравится ))
Это условие свыше, из бизнес процессов. У нас много проектов, и было принято решение сохранять единообразие, для более простого вхождения новичков на проект.
Вторая - у личного кабинета есть еще и публичная часть, в том числе и промо-лендинг. Да, звучит возможно странно. Изначально это были разные проекты, но позже стало выгодно их объединить, так как они стали делить один и тот же функционал.
Спасибо за развернутый ответ. Прошу прощения что пропал - не хотелось отвечать на бегу..
Давайте по порядку. Пример выше очень не плох для очень маленького проекта, как в примере. Об этом и документация FSD говорит. Для одностраничного приложения нет смысла так заморачиваться. Если проект все же крупнее вашего примера, то неизбежно будет расти беспорядок в этих папках. Беспорядок будет заключаться в высокой связности. Так как в данной структуре нет никаких ограничений на импорт модулей, то рано или поздно всё начинает зависеть от всего. И нет возможности внести правки не поломав функционала на других страницах. Мы такой же структуры придерживались на проекте, который в итоге вырос в итоге до 20 или 30 Мбайт исходного кода. Поддерживать это было очень сложно. Это на мой взгляд одна из самых плохих архитектур, которую масштабировать очень и очень сложно.
По поводу "закрыл гештальт" - суть именно в том что FSD формализована. Она описана и аргументирована. Архитектура выше - классическая, но она нигде не описана и не задокументирована. Если у кого-то возникают трудности, то совсем некуда обращаться и не с чем сравнить. Каждый разраб будет принимать решение на основе своего предпочтения, которое может быть весьма недальновидным. В противовес этому FSD дает четкие ответы на большинство вопросов, а в случае частных моментов - есть чат, где можно спросить совета у грамотных людей. И это огромный плюс на мой взгляд.
Вот просто вопрос, например какой реальный плюс разделять model и api?
Да бог с Вами не делите. Никто не заставляет. Состав сегментов не регламентирован FSD. Цитирую доку:
Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей
В моем случае деление на model и api неизбежно, потому что мы используем Redux, а он не допускает хранения несериализцемых данных. Если вы не пользуетесь Redux, вы можете все сложить в models или какой-то другой сегмент, на ваше усмотрение.
Основной принцип FSD не в "излишнем дроблении", а больше в том, что бы выстроить иерархию слоев и запретить хаотичных импорт, который повышает связность проекта.
Второй плюс, который дает FSD - легкий перенос функционала из одного проекта в другой. Надо лишь перенести несколько слайсов из 4-5 слоев. В случае с вашей архитектурой, надо будет бегать по файликам и копировать код буквально кусками - это знаем, проходили.
Во первых я не соглашусь с Вашим мнением о бесполезности FSD. Вы же, очевидно, её даже не пробовали, не знаете плюсов и не знаете минусов. Не очень тактично делать заявления обладая нулевым опытом. Если я не прав, то прошу прощения! Но тогда хотелось бы от Вас услышать развернутый ответ, с какими трудностями Вы столкнулись в работе с FSD, чем она вам так не прельстила? Все же продуктивнее обменяться опытом, чем переливать из пустого в порожнее.
А во вторых. Я говорил именно о том, что FSD своего рода "закрыла гештальт". Во Frontend-мире с момента популяризации SPA появилось очень много всего. Но не было именно грамотной, продуманной методологии. Были десятки (если не сотни) стейт-менеджеров, сборщиков пакетов, эффект-менеджеров, API-клиентов, css-процессоров, видов роутинга и инициализации проекта. А вот архитектурных методологий такого уровня, с такой детализации - нет. Пусть это и не GameChanger, но это серьезный шаг в сторону ответа на вопрос, который разработчики всегда решали сами у себя на коленке.
На мой взгляд сравнивать методологию с библиотеками крайне странно... любая библиотека плоха тем, что разработчику приходится вписывать свое приложение в её ограничения. И если что-то тебе в библиотеке не нравится есть всего три варианта:
попросить разрабов внести правки / принять твой пулл-реквест.
сделать форк и использовать свою версию либы, с необходимостью вручную её обновлять и править конфликты.
смириться и писать костыли.
Методологии хороши тем, что ты не ограничен в их использовании и применении. Методология - это лишь свод рекомендаций. Ты можешь её использовать частично, можешь её изменить под свои требования. Если для специфики вашего приложения FSD - это всего 10% пользы, то вы вправе применять FSD только на 10%. В методологии же главное - э то не код, а принципы его реализации.
Ну и про мимолетность: Agile-методололгии никуда не ушли. БЭМ никуда не ушел. Даже TDD вполне жив и применяется. У меня подозрение, что FSD тоже имеет все шансы прижиться в том или ином виде, ибо ничего настолько формализованного просто напросто еще не существует. Вакантное место совершенно пусто.
Не очень понятно из Ваших слов, что значит "через пару дней может делать фичи".
Если в вашем коллективе допускается, что через пару дней новичка можно выпустить в свободное плавание и пусть делает как хочет, то это скорее свидетельствует о низких стандартах качества кода и фривольности в разработке, чем о грамотности архитектуры. На мой взгляд ни одна, подробно описанная методология/архитектура не способна дать такой быстрый вход. Если в коллективе есть определенная культура, то любого новичка независимо от грейда приходится направлять и помогать адаптироваться минимум месяц, ибо все приходят со своим багажом знаний и мыслей на счет того, как должен писаться код.
Если речь о том, что новичку придется изучать одну только методологию два дня, что бы приступить к разработке, то это не так. Я вообще не вижу проблем разобраться в ней за пару часов с хорошим ментором. В FSD нет абсолютно ничего сверхъестественного. Она не сложнее, чем любая другая методология, по которой я работал, будь-то фрактальная, или container/components/state/api/etc или др.
По личному опыту, с импортами не вижу особых проблем, если честно. По началу было боязно, но как говорится, глаза бояться, а руки делают. Пока что было всего пара "узких" места, которые решились довольно легко.
А по поводу обилия слайсов тоже есть выход - fsd допускает их группировку (зря про это не написал в статье, кстати...) Поэтому можете группировать их как вам душе будет угодно и никакой плоскости не будет. Про глубину вложенности группировки я не уточнял, но мне кажется никто вас пинать не будет, если вы решите её делать многоуровневой
На мой взгляд число проектов в 10 страниц кратно превышает число проектов в 1000 страниц. Я бы сказал, даже, что немного сомневаюсь, существуют ли такие приложения, на 1000 страниц)) Ну это просто про релевантность проблематики вопроса.
Само собой, на такой сложности проект стоит проектировать что-то свое ибо это вовсе не банальная задача. Но, собственно, и документация FSD об этом говорит, что данная методология вовсе не панацея, но для многих она может быть очень даже полезной. Вы с этим не согласны?
"Отвергаешь - предлагай". Хотелось бы у знать Ваши предпочтения, что бы вы посоветовали, в качестве альтернативы для приложения среднего масштаба. Мы же здесь для обмена опытом и знаниями, не правда ли? ))
В контексте моего приложения документации не было вообще. На словах обсудили и пошли писать код. На данном проекте нас полтора землекопа, поэтому отложили этот момент на будущее, что не есть идеально. На других проектах, где я работал было что-то подобие свода правил. Иногда было подробно расписано, иногда не очень. Но во всех случаях не было такой подробной документации, как у FSD.
Конечно разночтения могут быть и будут, но тоже самое можно сказать и про другие проекты, где мы писали без FSD. Приходит новичок, ты ему что-то объясняешь, а он все равно делает по своему. И такая картина первый месяц или даже три, в зависимости от грейда. Это обычное дело. Но имея на руках документацию, наверное будет проще построить процесс "вливания" в коллектив, нежели без нее.
По масштабируемости - самая главная проблема с чем сталкивался это необходимость выносить модули, в основном модели, иногда представление списков, в common. То есть деление раз шло изначально отталкиваясь от бизнес-сущностей, если точнее от страниц, то и модели были как бы закреплены за этими страницами. И когда модель начинала учавствовать в других "страницах" то вставал вопрос - либо прибегать к кросс-импортам, что уже на подсознательном уровне не очень красиво, хоть мы такого правила не устанавливали. Либо выносить эту модель в Common. И Common со временем начинал расти и превращался в свалку.. его приходилось делить на какие-то выдуманные разделы: UIkit, lib, helpers, utils..
Соглашусь)) Но писать сложный проект вообще без методологии еще хуже, наверное
Я участвовал в разных проектах, на React+TS пишу уже 8 лет. По разному пытались строить архитектуру. Лично по моему опыту, FSD пока что лучшее из того, что я пробовал. Как минимум имея уже с десяток страниц в проекте (я в статье не все расписал, само собой), нет ощущения, что что-то не вписывается в эту структуру.
Возможно, Вы и правы. Спасибо за эту ремарку. В конце концов мы и сами только в начале знакомства с FSD.
Мне на самом деле сделали это же замечание буквально вчера, но я решил все же не править статью. Поясню за свои слова: на мой взгляд это все же зависит от специфики коллектива, навыков разработчика и требований бизнеса. При подходе "сверху вниз" на мой взгляд есть шанс скатиться в ситуацию, когда весь код накидан в спешке в page, проверен на работоспособность и отправлен на прод с надеждой в будущем это разобрать и отрефакторить. И вот этот самый рефакторинг не у всех случается. И вся идея FSD идет на смарку.
Если же двигаться снизу вверх, то вы чисто физически не нарушая законов FSD не сможете все разместить в entities. Вам придется что-то поднимать на более верхние уровни так или иначе.
Да, соглашусь, что это может тормозить скорость разработки, но это можно отнести ко многим методологиям. Да даже одним из минусов Typescript считается увеличение времени на разработку, но давайте будем честными, это меньшее из зол.
Информация
В рейтинге
Не участвует
Откуда
Тюмень, Тюменская обл. и Ханты-Мансийский АО, Россия
Вы про тип Props? В подавляющем большинстве случаев типы у каждого компонента свои.
Есть несколько случаев, компонентов-модификаторов, которые переиспользуют тип от основного блока (это если говорить терминами БЭМ) но они все в пределах одного слайса, поэтому проблем с импортами нет.
В остальном у каждого компонента свои типы. Мне кажется это вполне оправдано.
Во первых, спасибо за такой развернутый комментарий! Спасибо, что делитесь опытом!
Возможно это странно, но по моему опыту работы я сталкивался с большинством описанных трудностей на проектах без fsd - неоднозначность, куда разместить общую для сущностей логику, как содержать связные бизнесс-сущности, особенно если у них есть свои самостоятельные разделы. Свалка в lib, когнитивная нагрузка и тд.
Поэтому я склонен считать, что эти беды не от fsd, а от непонимания его.
Особенно, если говорить про связные бизнесс-сущности. Многие почему-то считают, что сущность - это класс. Я в корне не согласен. Если у вас есть механизм геолокаций, то там будет с дюжину классов - страна, город, индекс, улица, мкрн, дом, подъезд, этаж, квартира. Вы ж не станете это делить на 10 сущностей и потом пытаться объединить через надуманные механизмы?.. это бойлерплейт чистой воды.. Нет, сделайте одну сущность geolocation и радуйтесь. И то если это доменная сущность. А коли нет, то место ей в shared)))
Если у вас проект прям сильно крутится вокруг одной большой сущности, Которая связана сразу со всем в системе (а я встречал такие проекты) ну тогда может быть fsd тут не уместен. Это ж не панацея всё таки.
По части destructive decoupling - опять некорректное прочтение методологии. Я общался в чате на эту тему и мне сторожилы fsd предупредили, что не надо дробить, ради дробления. Всё должно быть компактно по возможности.
Это тоже не проблема fsd, а его прочтения. Человек приходит со своими тараканами в голове и пытается делать что-то новое по-старому и прогресса не получается. У меня то же самое произошло в процессе рефакторинга, слава богу мозги вправили и я быстренько всё переделал.
Забавно, но у меня эта проблема возникала всегда на предыдущих проектах, но не в fsd. В fsd я как-то разобрался за пару дней и всё наоборот стало предельно ясно. В моём случае fsd наоборот помог решить данную дилемму.
Мое мнение, что каждой технологии - своё время. А ещё мне кажется, что даже если и выйдет что-то нативное на JS, то без опыта реакта и всего, что его окружает, это было бы просто невозможно)) как минимум он задал вектор, куда стоит развивать отрасль.
Москва не сразу строилась))) да и тоже самое можно сказать и про любую другую технологичную область:
- Давайте изобретем двигатель. Изобрели ДВС.
- Блин, он греется сильно. Давайте добавим радиатор охлаждения.
- Эх, с балансом беда, его трясёт как девственницу в первую брачную ночь. Давайте добавим балансировочный вал.
- А вы заметили, что распредвалы не дают оптимальные фазы на всех диапазонах оборотов? Давайте придумаем VVT.
- Вы знаете сколько КПД тратится на нагрев? Давайте придумаем системы рекуперации?
Приходит Маск:
- я там очередную гигафабрику начал строить....
- бл...
Но разве это всё было бессмысленно, вы скажите? =)))
Речь только про наш бизнесс-юнит)
Были мысли и про монорепы и про субмодули и даже про пакет в npm.. выбрали путь объединения проектов. Тем более, что это вполне было логично и с других течек зрения.
В плане NextJS спорить не буду. Мне лично он тоже не нравится ))
Причин две:
Это условие свыше, из бизнес процессов. У нас много проектов, и было принято решение сохранять единообразие, для более простого вхождения новичков на проект.
Вторая - у личного кабинета есть еще и публичная часть, в том числе и промо-лендинг. Да, звучит возможно странно. Изначально это были разные проекты, но позже стало выгодно их объединить, так как они стали делить один и тот же функционал.
Спасибо за развернутый ответ. Прошу прощения что пропал - не хотелось отвечать на бегу..
Давайте по порядку. Пример выше очень не плох для очень маленького проекта, как в примере. Об этом и документация FSD говорит. Для одностраничного приложения нет смысла так заморачиваться. Если проект все же крупнее вашего примера, то неизбежно будет расти беспорядок в этих папках. Беспорядок будет заключаться в высокой связности. Так как в данной структуре нет никаких ограничений на импорт модулей, то рано или поздно всё начинает зависеть от всего. И нет возможности внести правки не поломав функционала на других страницах. Мы такой же структуры придерживались на проекте, который в итоге вырос в итоге до 20 или 30 Мбайт исходного кода. Поддерживать это было очень сложно. Это на мой взгляд одна из самых плохих архитектур, которую масштабировать очень и очень сложно.
По поводу "закрыл гештальт" - суть именно в том что FSD формализована. Она описана и аргументирована. Архитектура выше - классическая, но она нигде не описана и не задокументирована. Если у кого-то возникают трудности, то совсем некуда обращаться и не с чем сравнить. Каждый разраб будет принимать решение на основе своего предпочтения, которое может быть весьма недальновидным. В противовес этому FSD дает четкие ответы на большинство вопросов, а в случае частных моментов - есть чат, где можно спросить совета у грамотных людей. И это огромный плюс на мой взгляд.
Да бог с Вами не делите. Никто не заставляет. Состав сегментов не регламентирован FSD. Цитирую доку:
В моем случае деление на model и api неизбежно, потому что мы используем Redux, а он не допускает хранения несериализцемых данных. Если вы не пользуетесь Redux, вы можете все сложить в models или какой-то другой сегмент, на ваше усмотрение.
Основной принцип FSD не в "излишнем дроблении", а больше в том, что бы выстроить иерархию слоев и запретить хаотичных импорт, который повышает связность проекта.
Второй плюс, который дает FSD - легкий перенос функционала из одного проекта в другой. Надо лишь перенести несколько слайсов из 4-5 слоев. В случае с вашей архитектурой, надо будет бегать по файликам и копировать код буквально кусками - это знаем, проходили.
Увы, но Вы не так трактуете мои слова.
Во первых я не соглашусь с Вашим мнением о бесполезности FSD. Вы же, очевидно, её даже не пробовали, не знаете плюсов и не знаете минусов. Не очень тактично делать заявления обладая нулевым опытом. Если я не прав, то прошу прощения! Но тогда хотелось бы от Вас услышать развернутый ответ, с какими трудностями Вы столкнулись в работе с FSD, чем она вам так не прельстила? Все же продуктивнее обменяться опытом, чем переливать из пустого в порожнее.
А во вторых. Я говорил именно о том, что FSD своего рода "закрыла гештальт". Во Frontend-мире с момента популяризации SPA появилось очень много всего. Но не было именно грамотной, продуманной методологии. Были десятки (если не сотни) стейт-менеджеров, сборщиков пакетов, эффект-менеджеров, API-клиентов, css-процессоров, видов роутинга и инициализации проекта. А вот архитектурных методологий такого уровня, с такой детализации - нет. Пусть это и не GameChanger, но это серьезный шаг в сторону ответа на вопрос, который разработчики всегда решали сами у себя на коленке.
На мой взгляд сравнивать методологию с библиотеками крайне странно... любая библиотека плоха тем, что разработчику приходится вписывать свое приложение в её ограничения. И если что-то тебе в библиотеке не нравится есть всего три варианта:
попросить разрабов внести правки / принять твой пулл-реквест.
сделать форк и использовать свою версию либы, с необходимостью вручную её обновлять и править конфликты.
смириться и писать костыли.
Методологии хороши тем, что ты не ограничен в их использовании и применении. Методология - это лишь свод рекомендаций. Ты можешь её использовать частично, можешь её изменить под свои требования. Если для специфики вашего приложения FSD - это всего 10% пользы, то вы вправе применять FSD только на 10%. В методологии же главное - э то не код, а принципы его реализации.
Ну и про мимолетность: Agile-методололгии никуда не ушли. БЭМ никуда не ушел. Даже TDD вполне жив и применяется. У меня подозрение, что FSD тоже имеет все шансы прижиться в том или ином виде, ибо ничего настолько формализованного просто напросто еще не существует. Вакантное место совершенно пусто.
Да, по поводу новичка я вас понял, что речь не про джуна))
За Ваш опыт спасибо. Быть может и он будет полезен. Но пока склоняюсь к тому, что это спор о вкусах.
Фидбек да! если будет, что сказать, вполне возможно будет и продолжение статьи))
Не очень понятно из Ваших слов, что значит "через пару дней может делать фичи".
Если в вашем коллективе допускается, что через пару дней новичка можно выпустить в свободное плавание и пусть делает как хочет, то это скорее свидетельствует о низких стандартах качества кода и фривольности в разработке, чем о грамотности архитектуры. На мой взгляд ни одна, подробно описанная методология/архитектура не способна дать такой быстрый вход. Если в коллективе есть определенная культура, то любого новичка независимо от грейда приходится направлять и помогать адаптироваться минимум месяц, ибо все приходят со своим багажом знаний и мыслей на счет того, как должен писаться код.
Если речь о том, что новичку придется изучать одну только методологию два дня, что бы приступить к разработке, то это не так. Я вообще не вижу проблем разобраться в ней за пару часов с хорошим ментором. В FSD нет абсолютно ничего сверхъестественного. Она не сложнее, чем любая другая методология, по которой я работал, будь-то фрактальная, или container/components/state/api/etc или др.
По личному опыту, с импортами не вижу особых проблем, если честно. По началу было боязно, но как говорится, глаза бояться, а руки делают. Пока что было всего пара "узких" места, которые решились довольно легко.
А по поводу обилия слайсов тоже есть выход - fsd допускает их группировку (зря про это не написал в статье, кстати...) Поэтому можете группировать их как вам душе будет угодно и никакой плоскости не будет. Про глубину вложенности группировки я не уточнял, но мне кажется никто вас пинать не будет, если вы решите её делать многоуровневой
На мой взгляд число проектов в 10 страниц кратно превышает число проектов в 1000 страниц. Я бы сказал, даже, что немного сомневаюсь, существуют ли такие приложения, на 1000 страниц)) Ну это просто про релевантность проблематики вопроса.
Само собой, на такой сложности проект стоит проектировать что-то свое ибо это вовсе не банальная задача. Но, собственно, и документация FSD об этом говорит, что данная методология вовсе не панацея, но для многих она может быть очень даже полезной. Вы с этим не согласны?
"Отвергаешь - предлагай". Хотелось бы у знать Ваши предпочтения, что бы вы посоветовали, в качестве альтернативы для приложения среднего масштаба. Мы же здесь для обмена опытом и знаниями, не правда ли? ))
>отсутствие формализованной методологии
В контексте моего приложения документации не было вообще. На словах обсудили и пошли писать код. На данном проекте нас полтора землекопа, поэтому отложили этот момент на будущее, что не есть идеально. На других проектах, где я работал было что-то подобие свода правил. Иногда было подробно расписано, иногда не очень. Но во всех случаях не было такой подробной документации, как у FSD.
Конечно разночтения могут быть и будут, но тоже самое можно сказать и про другие проекты, где мы писали без FSD. Приходит новичок, ты ему что-то объясняешь, а он все равно делает по своему. И такая картина первый месяц или даже три, в зависимости от грейда. Это обычное дело. Но имея на руках документацию, наверное будет проще построить процесс "вливания" в коллектив, нежели без нее.
По масштабируемости - самая главная проблема с чем сталкивался это необходимость выносить модули, в основном модели, иногда представление списков, в common. То есть деление раз шло изначально отталкиваясь от бизнес-сущностей, если точнее от страниц, то и модели были как бы закреплены за этими страницами. И когда модель начинала учавствовать в других "страницах" то вставал вопрос - либо прибегать к кросс-импортам, что уже на подсознательном уровне не очень красиво, хоть мы такого правила не устанавливали. Либо выносить эту модель в Common. И Common со временем начинал расти и превращался в свалку.. его приходилось делить на какие-то выдуманные разделы: UIkit, lib, helpers, utils..
Прошу прощения, я не понял вопроса.
Соглашусь)) Но писать сложный проект вообще без методологии еще хуже, наверное
Я участвовал в разных проектах, на React+TS пишу уже 8 лет. По разному пытались строить архитектуру. Лично по моему опыту, FSD пока что лучшее из того, что я пробовал. Как минимум имея уже с десяток страниц в проекте (я в статье не все расписал, само собой), нет ощущения, что что-то не вписывается в эту структуру.
Возможно, Вы и правы. Спасибо за эту ремарку. В конце концов мы и сами только в начале знакомства с FSD.
Мне на самом деле сделали это же замечание буквально вчера, но я решил все же не править статью. Поясню за свои слова: на мой взгляд это все же зависит от специфики коллектива, навыков разработчика и требований бизнеса. При подходе "сверху вниз" на мой взгляд есть шанс скатиться в ситуацию, когда весь код накидан в спешке в page, проверен на работоспособность и отправлен на прод с надеждой в будущем это разобрать и отрефакторить. И вот этот самый рефакторинг не у всех случается. И вся идея FSD идет на смарку.
Если же двигаться снизу вверх, то вы чисто физически не нарушая законов FSD не сможете все разместить в entities. Вам придется что-то поднимать на более верхние уровни так или иначе.
Да, соглашусь, что это может тормозить скорость разработки, но это можно отнести ко многим методологиям. Да даже одним из минусов Typescript считается увеличение времени на разработку, но давайте будем честными, это меньшее из зол.