Почему же безальтернативно? Они вполне приятны после определенного рефакторинга и осмысления. В нем стоят интересные задачи и меньше свалки чем в растущем проекте на классической структуре. Поэтому я скорее сочувствую тем кто вынужден работать в ее рамках.
Проблема в том, что в итоге у вас все теже десять слоев, притом, все лежащее в них лежит в глобальном пространстве. У меня же, почти все лежит в одном домене/папке. В итоге у меня чисто физически не может стать много файлов на одном уровне.
Проблема в моем опыте: я обычно прихожу на большие проекты на которые люди потратили десятки или сотни тысяч часов. И там видны все проблемы, к которым приводит следование классическому разбиению.
Не совсем понимаю почему вы все хотите складывать в страницы. Даже если их 0 или 2+.
Не стоит бросаться словами про высланные из пальца примеры. Прежде чем думать что ваш собеседник неправ, возможно стоит разобраться а верно ли вы его поняли, и насколько его опыт отличается от вашего. К примеру с кнопкой вы точно меня не поняли: базовая кнопка это хорошо. Но я говорю о кнопке которая повторяется из раза в раз, но отличается от базовой и это хорошо было бы где-то закрепить. Обычно это привязано к домену.
Вот взять пример с модалками: вы их сложили в модалки. Отлично. Но там 7 модалок на 3 разных сценария. Более того, у них есть ещё несколько специфических визуальных компонентов, которые имеют значение в рамках работы с емвйлом, но не имеют никакого значения за его рамками. Например, какие-то специфические кнопки. И конечно же у вас есть что-то, что хранит сами сценарии вызова этих модалок. Для примера пусть это будет какой-то отдельный компонент, который вы на верхний уровень роутинга складываете и так он доступен на всех страницах.
В разбиении по домены это будет: у вас из домена торчит одна ручка с верхнецровневым компонентом, а уже в самом домене сокрыты сценарии утилиты и компоненты.
В вашей структуре будут два варианта:
Все модалки, компоненты и утилиты лежат на верхних уровнях components/ utils/ hooks/. Могу смело сказать, что при наличии 10+ таких сущностей навигация в проекте становится возможной только по прямым ссылкам в файлы.
На каждом уровне создаётся ./emailConfirmation. (На практике никто под один хук не создаст такую папку и он потеряется в общей куче). В итоге, что-то просачивается в глобальное пространство имён, а что-то лежит в папке. Но нигде не обозначено в явном виде должно оно использоваться напрямую или оно имеет смысл только в контексте определенного домена
Такое ощущение будто вы не совсем понимаете про, что я говорю.
Я как раз и указываю что при определенном росте проекта проект превращается в свалку и "классическое" разбиение перестает эффективно справляться.
Решение, но решение через микрофронты, только ради этой проблемы - избыточно. Ничего принципиально не поменяется для вас в плане разбиения, если вы вместо микрофронтендов начнёте использовать тоже самое разбиение на домены но на уровне одного проекта.
Поэтому меня откровенно удивляет, что клерик вначале строго выступал против разбиения по домены, но потом выступил за микрофронты - которые и производят разбиение на домены. Ваше разбиение "в глубину" когда вы помещаете все в страницу - ничем не отличается от выделения домена. Кроме одного странного аспекта: вы все ещё домен называете страницей, хотя в нем может быть их как и 0 так и 10. Вы уверены что называть это страницей всё ещё хорошая идея?
Если мы принимаем, что концепция разбиения кода по доменным областям жизнеспособна, и хорошо работает на определенных проектах, то не совсем понятно, почему фсд встречает такое большое сопротивление, ведь он сильно следует этой идее. Вот к примеру вы тоже говорите что есть "наиболее грамотный выбор структуры". Можно хотя бы два примера общеизвестной структуры решающей проблему разбиения кода на большом проекте (когда классика уже хуже работает)?
Исходя из названия назначения этих компонентов понятны
Конечно. А вот когда у вас рядом лежит 20 кнопок, а ещё некоторые компоненты выглядят как кнопки, но по настоящему виджеты, а ещё часть кнопок лежит в страницах, так как подумалось что они слишком частные, то узнать о наличии нужного кода: задача уже не тривиальная.
Проблема в том, что вы рассматриваете очень простые и примитивные кейсы. Ваш пример со страницами - по сути это частный случай разбития по доменным областям.
А вот к примеру кейс: есть несколько связных модалок и виджетов отвечающих за подписку пользователя, и вот уже они не попадают под определение страницы, а выделить их было бы хорошо. Так что изменится если вы вдруг на верхнем уровне будете использовать не pages, а допустим modules?
Или у нас есть функционал по показу надоедливого баннера с предложение включить пуши. У него так же может отсутствовать страница.
Дальше ещё интереснее получается: вот у нас есть дефолтная кнопка из кита с 3-5 разными дизайнами.
И допустим кнопка которая меняет дизайн в зависимости от наличия подписки или ее отсутствия. Вопрос: вы ее куда сложите? В кнопки? Тогда у вас там помимо базовой кнопки будет десяток других кнопок. А если она в место кнопки будет ещё отображать значок, то ее всё ещё имеет смысл хранить в кнопках? Или вы в страницу положите? А из уже 3 разные. Объедините их в группу? Хмм кажется тогда это уже не страница. И где искать эту кнопку, и знать что ее уже реализовал кто-то?
О а вот ещё пример: вам нужно отображать номер карты на странице с определенным форматированием. Где сложить функцию форматирования? В utils? А там уже сотня разных других форматирований для других сущностей, так как форматирование повторяется из раза в раз.
Нет, в первую очередь я веду к тому что на любом более менее большом проекте разделение проекта по доменным областям - существенно упрощает навигацию в проекте и уменьшает связность кода.
Человек выше, активно спорил с этим. Когда я перечислил какие проблемы решает разбиение на домены, он пытался парировать тем, что это все можно решить через микрофронты. Но микрофронты - это тоже самое разбиение на домены + ещё несколько плюсов и минусов, которые как могут быть нужны так и вредить.
По сути, не так важно, вынесли вы домен в отдельный микрофронт/модуль/приложение/пакет. Ключевой момент, что это позволяет снизить свалку в коде.
Так и никто не говорит, что микрофронтендов не помогут против свалки. Но все тоже самое можно достичь и в монорепе и без микрофронтов.
Проблема в том, что вы применяете инструмент, который решает сразу несколько проблем (и привносит некоторые другие) для решения одной проблемы. Но почему-то против другого решения которое решает только одну, но нужную нам.
Все верно вы говорите: действительно на многих проектах домены легко связываются со страницами. Но если она уже выросла до десятка подстраниц, верно ли ее всё ещё называть "страница"? Более того бывает функционал который вообще страниц не имеет, а только виджеты или компоненты.
Мы конечно можем выделить это в микрофронт, но какой в этом смысл? Его настройка сложнее и зачастую ведёт к накладным расходам. В то время как выделение домена в рамках монорепы - максимально простое, позволяет быстро обновлять связи интерфейсы и подключать новые через обычный импорт экспорт. И в том числе использовать общие библиотеки.
Я не против микрофронтов, они классные если нам нужно решить проблему с разделением релизов между командами. Но применять их только ради разбиения кода по доменам? Кажется все тоже самое можно сделать и без микрофронтендов, но проще.
Микрофронтенд это часть проекта выделенная отдельно. Более того она даже не обязательно должно быть в другом репозитории и иметь сильную свободу по подходам и архитектуре. Более того, на фронте, в отличии от бэка это приводит к большим проблемам с увеличением бандла и скорости работы приложения.
Нет никакой разницы монореп вы используете или нет, прова код овнера могут быть разбиты по папкам а не по репозиториям.
Вы высказали идею, что переход на микрофронты решит нашу проблему разбиения кода. Но все тоже самое можно получить не разбивая репозиторий на много маленьких, и не организовывая погрузку каждого микрофронтенда отдельно, что приводит к увеличению размера.
С тем же успехом можно сказать что любое разбиение проекта на уровни "вводит дополнительные ограничения и неудобства", но на практике оно необходимо особенно при росте проекта.
я думаю вы не верно ставите соотношение применяемости этого разбиения. Я бы сказал, что наоборот на больших проектах куда чаще разбиение по доменам отлично помокает.
Но вы подняли отличный вопрос: а зачем это на маленьких проектах? Все верно, там это и не нужно, но там будет логично поднять вопрос и про уместность реакта. Ведь реакт это тоже самое - мы инвестируем ресурсы, что бы потом возможно получить бенефит.
то что есть и другие проблемы - не говорит о том, что это решение частного случая - плохое. Более того - хорошо структурированный и понятный проект позволет лучше его понимать, и соотвественно его и рефакторить проще снижая техдол, и от дублирования кода избавлятся, и переосмысливать связи между компонентами. Все эти шаги проще делать при разбиении по доменам. Вы сами указали, что те проблемы, на которые я указывал, хорошо решаются микрофронтами. Если вы рассматриваете микрофронты как адекватное решение которое приносит бенефиты на большой проект, то почему вы так сильно выступаете против разбиения не домены?
Ну и кстати если рассуждать про абстрактный огромный проект, где есть "мусорка", то этот проект должен быть разбит на микрофронты, причем заранее, до появление этой самой "мусорки". И тут уже бац и все эти драматизированные проблемы файлов и папок опять улетучиваются сразу)
а микрофронты в итоге и есть то самое разбиение по доменным областям (с оговорочками). И вот эти оговорочки приводят к тому, что проще и эффективнее работать в рамках одного продукта разбив на домены.
Это не какой-то абстрактный проект. Три моих последних проекта были именно такмими, и только в одном мы делали переход на микрофронты. И этот переход был обусловлен не тем что нужно разбить на домены(это разбиение прекрасно выполняется и без микрофронтов), а тем что хотелось развязать релизный цикл между командами и где каждая команда выполняла релиз отдельно
И где проблема? Все сгруппировано. Все логично и все понятно.
в итоге в идеальном мире все сведется к или
components/order
hooks/order
и наоборот
order/components
order/hooks
И казалось бы в чем разница, ведь меняем шило на мыло? что вам в компонентс искать ключевое слово order?Но проблема в том, что в одном случае мы явно закрепили домен на самом верхнем уровне, в другом групировка постепенно прорастает, и тут возможны рсхождения. Так же проще отслеживать зависимости из одного раздела, который в явном виде поставляет, что хочет отдать, чем из десятков файлов по одному.
Вы выдумали сценарий где проект пишут джуны или вообще неадекваты.
увы, но нет. Мало кто нормально поддерживает нормальное именнование подгрупировки синхронизированное между components, helpres ... Да и в принципе это довольно странно:может быть на один домен 30 коммпонентов, и один хук. Что мы будем в этом случае делать? в каждом разделе создавать подраздел по домену? а если не создадим, то нужно будет помнить про то, что для вот этого домена есть хук?
Плюс вы фантазируете со сложность поиска. Во первых есть ctrl + f, во вторых, вы знаете где нужный вам компонент находится на странице, допустим вам надо пофиксить сворачивающийся блок на странице товара, он идет сразу после блока описание, зашли в
конечно если мы знаем точное имя компонента или знаем как точно его найти - то никакой сложности нет. Но ведь кейсы не все настолько простые? Довольно часто нам нужно вообще посмотреть что уже написанно по определенной предметной области, но точное именование может быть совсершенно разным. На маленьком продукте мы еще можем попробовать пройти все сценарии и попытатся найти подобное. Но на большом это уже затруднительно.
Если не драматизировать вещи, которые являются нашей работой, то оказывается что все легко и просто и проблем то и нет в общем-то. Просто бери да делай. И палки в колеса себе не вставляй и не усложняй простые вещи на ровном месте.
вот вот, казалось бы разбей все сразу на нормальные разделы по доменам и не гадай потом где и что написанно по этой предметной области, но почему-то у некоторых людей жгучее желание свалить это в одну кучу.
все верно, когда их становится в "куче" много, их начинают групировать в этой куче. Более того, как правило это приводит и к тому что в других "кучах" так же возникает необходимость групировки. в итоге у нас /orderSpecified повторяется в нескольких разделах. И самое веселое когда в одном разделе это уже сгрупированно, а в другом нет, и там начинают групировку. Это часто приводит к тому , что появляются расхождения.
Идея же групировки по бизнесу разворачивает порядок групировки - вначале идет домен, а уже потом любое удобное разбиение (в том числе и классическое). В таком случае вам сложнее получить разные имена и сразу видно весь функционал по определенной доменной области. Это отсекает разные проблемы от поиска функционала по домену: например components/cart/... и components/order/... (и попробуй угадай как это назвал прошлый разраб), в то время как уровень ниже уже легко разбивается по любой другой системе со строго определенными разделами.
Так же я заметил, что у вас смешаны в кучу бизнес компоненты и инструментальные примитвы. Если мы разбиваем по доменам, то никто не машает нам вынести инструменты общие для проекта в shared. Это позволяет лучше понимать какими инструментами мы обладаем, а не разбираться в мешанине: бизнес/не бизнес.
отлично, то есть у вас оно в глобальное пространство уходит. И как я понимаю компоненты отвечающие за его отображение так же уходят в глобальную папку components?
Это работает в обе стороны. Может это вы не понимаете фсд и о чем говорит ваш собеседник?
Окей. Допустим у вас тысяча страниц и 10 из них использует одну и туже функцию или компонент который завязан на бизнес. Где вы его разместите в данной структуре? У вас из вариантов тольк либо его привязать к странице, либо скинуть в кучу. В первом варианте у вас страница выступает в роли домена, а в другом варианте у вас начинает копиться свалка в общих компонентах, так как вы туда помещаете все общие компоненты по всем доменам.
возмем вашу схему и попробуем разложить несколько хуков привязанных к бизнесу. Допустим хук получения списка товаров активного заказа вы как в этой схеме расположите? Ну или любой другой бизнес хук который может использоваться сразу в нескольких компонентах?
отлично, этот хук не привязан к сущности и складывается в shared.
а вот допустим: hooks/useOrderItems - уже привязан к заказу и его можно положить в домен заказа. Зачем он мне на глобальном уровне, если я использую его только для некоторых компонентов (которые так же привязаны к этому домену)?
Все зависит от размера проекта. Если у вас 20 хуков, то конечно нет ничего плохого в классическом разбиении. Когда их перешагивает за 200? отслеживать то , что уже написано по определенному домену - становится очень сложно
Это просто слова, которые ничего не значат. Любой может использовать этот трюк.
И да, и нет. Классическое разбиение не предлагает хороших решений для проблемы роста числа файлов объединенных по одному типу. Соответственно на больших проектах это приводит к свалкам. Если у вас есть контр примеры, я с радостью их услышу. Но пока весь мой опыт это только подтверждает
Распределение по домменым облостям упрощает поиск и навигацию. Одно дело когда у нас свалены все компоненты в одну кучу, а еще к ним идут свои хелперы, утилиты, хуки, модели, обработчики. В итоге у вас на верхнем уровне доступно сразу все. На более менее большом проекте это приводит к сотням файлов в каждой категории, и делает поиск по ним банально неудобным. Иногда становится сложно даже понять по какому ключевому слову мы можем найти уже написанный код.
В то же время, разбив это в первую очередь по доменам мы сужаем область поиска, так как весь код связанный с определенным функционалом находится в одном месте.
Я не вижу ни одной причины отказыватся от разбиения на домены, ведь из всей принципиальной разницы с классикой мы получаем удобную верхнеуровневую групировку. Конечно в fsd этой разницы больше, но в целом они следуют похожей идее.
Почему же безальтернативно? Они вполне приятны после определенного рефакторинга и осмысления. В нем стоят интересные задачи и меньше свалки чем в растущем проекте на классической структуре. Поэтому я скорее сочувствую тем кто вынужден работать в ее рамках.
Проблема в том, что в итоге у вас все теже десять слоев, притом, все лежащее в них лежит в глобальном пространстве. У меня же, почти все лежит в одном домене/папке. В итоге у меня чисто физически не может стать много файлов на одном уровне.
Проблема в моем опыте: я обычно прихожу на большие проекты на которые люди потратили десятки или сотни тысяч часов. И там видны все проблемы, к которым приводит следование классическому разбиению.
Не совсем понимаю почему вы все хотите складывать в страницы. Даже если их 0 или 2+.
Не стоит бросаться словами про высланные из пальца примеры. Прежде чем думать что ваш собеседник неправ, возможно стоит разобраться а верно ли вы его поняли, и насколько его опыт отличается от вашего. К примеру с кнопкой вы точно меня не поняли: базовая кнопка это хорошо. Но я говорю о кнопке которая повторяется из раза в раз, но отличается от базовой и это хорошо было бы где-то закрепить. Обычно это привязано к домену.
Вот взять пример с модалками: вы их сложили в модалки. Отлично. Но там 7 модалок на 3 разных сценария. Более того, у них есть ещё несколько специфических визуальных компонентов, которые имеют значение в рамках работы с емвйлом, но не имеют никакого значения за его рамками. Например, какие-то специфические кнопки. И конечно же у вас есть что-то, что хранит сами сценарии вызова этих модалок. Для примера пусть это будет какой-то отдельный компонент, который вы на верхний уровень роутинга складываете и так он доступен на всех страницах.
В разбиении по домены это будет: у вас из домена торчит одна ручка с верхнецровневым компонентом, а уже в самом домене сокрыты сценарии утилиты и компоненты.
В вашей структуре будут два варианта:
Все модалки, компоненты и утилиты лежат на верхних уровнях components/ utils/ hooks/. Могу смело сказать, что при наличии 10+ таких сущностей навигация в проекте становится возможной только по прямым ссылкам в файлы.
На каждом уровне создаётся ./emailConfirmation. (На практике никто под один хук не создаст такую папку и он потеряется в общей куче). В итоге, что-то просачивается в глобальное пространство имён, а что-то лежит в папке. Но нигде не обозначено в явном виде должно оно использоваться напрямую или оно имеет смысл только в контексте определенного домена
Такое ощущение будто вы не совсем понимаете про, что я говорю.
Я как раз и указываю что при определенном росте проекта проект превращается в свалку и "классическое" разбиение перестает эффективно справляться.
Решение, но решение через микрофронты, только ради этой проблемы - избыточно. Ничего принципиально не поменяется для вас в плане разбиения, если вы вместо микрофронтендов начнёте использовать тоже самое разбиение на домены но на уровне одного проекта.
Поэтому меня откровенно удивляет, что клерик вначале строго выступал против разбиения по домены, но потом выступил за микрофронты - которые и производят разбиение на домены. Ваше разбиение "в глубину" когда вы помещаете все в страницу - ничем не отличается от выделения домена. Кроме одного странного аспекта: вы все ещё домен называете страницей, хотя в нем может быть их как и 0 так и 10. Вы уверены что называть это страницей всё ещё хорошая идея?
Если мы принимаем, что концепция разбиения кода по доменным областям жизнеспособна, и хорошо работает на определенных проектах, то не совсем понятно, почему фсд встречает такое большое сопротивление, ведь он сильно следует этой идее. Вот к примеру вы тоже говорите что есть "наиболее грамотный выбор структуры". Можно хотя бы два примера общеизвестной структуры решающей проблему разбиения кода на большом проекте (когда классика уже хуже работает)?
Конечно. А вот когда у вас рядом лежит 20 кнопок, а ещё некоторые компоненты выглядят как кнопки, но по настоящему виджеты, а ещё часть кнопок лежит в страницах, так как подумалось что они слишком частные, то узнать о наличии нужного кода: задача уже не тривиальная.
Проблема в том, что вы рассматриваете очень простые и примитивные кейсы. Ваш пример со страницами - по сути это частный случай разбития по доменным областям.
А вот к примеру кейс: есть несколько связных модалок и виджетов отвечающих за подписку пользователя, и вот уже они не попадают под определение страницы, а выделить их было бы хорошо. Так что изменится если вы вдруг на верхнем уровне будете использовать не pages, а допустим modules?
Или у нас есть функционал по показу надоедливого баннера с предложение включить пуши. У него так же может отсутствовать страница.
Дальше ещё интереснее получается: вот у нас есть дефолтная кнопка из кита с 3-5 разными дизайнами.
И допустим кнопка которая меняет дизайн в зависимости от наличия подписки или ее отсутствия. Вопрос: вы ее куда сложите? В кнопки? Тогда у вас там помимо базовой кнопки будет десяток других кнопок. А если она в место кнопки будет ещё отображать значок, то ее всё ещё имеет смысл хранить в кнопках? Или вы в страницу положите? А из уже 3 разные. Объедините их в группу? Хмм кажется тогда это уже не страница. И где искать эту кнопку, и знать что ее уже реализовал кто-то?
О а вот ещё пример: вам нужно отображать номер карты на странице с определенным форматированием. Где сложить функцию форматирования? В utils? А там уже сотня разных других форматирований для других сущностей, так как форматирование повторяется из раза в раз.
Нет, в первую очередь я веду к тому что на любом более менее большом проекте разделение проекта по доменным областям - существенно упрощает навигацию в проекте и уменьшает связность кода.
Человек выше, активно спорил с этим. Когда я перечислил какие проблемы решает разбиение на домены, он пытался парировать тем, что это все можно решить через микрофронты. Но микрофронты - это тоже самое разбиение на домены + ещё несколько плюсов и минусов, которые как могут быть нужны так и вредить.
По сути, не так важно, вынесли вы домен в отдельный микрофронт/модуль/приложение/пакет. Ключевой момент, что это позволяет снизить свалку в коде.
Если посмотреть разные вариации i18n, то довольно часто они сами все это реализовывают и не совсем понятно зачем что-то класть в redux.
Файлы прекрасно кешируются браузером, и если у вас переводы не обновляются по несколько раз в час - это не должно быть проблемой.
Так и никто не говорит, что микрофронтендов не помогут против свалки. Но все тоже самое можно достичь и в монорепе и без микрофронтов.
Проблема в том, что вы применяете инструмент, который решает сразу несколько проблем (и привносит некоторые другие) для решения одной проблемы. Но почему-то против другого решения которое решает только одну, но нужную нам.
Все верно вы говорите: действительно на многих проектах домены легко связываются со страницами. Но если она уже выросла до десятка подстраниц, верно ли ее всё ещё называть "страница"? Более того бывает функционал который вообще страниц не имеет, а только виджеты или компоненты.
Мы конечно можем выделить это в микрофронт, но какой в этом смысл? Его настройка сложнее и зачастую ведёт к накладным расходам. В то время как выделение домена в рамках монорепы - максимально простое, позволяет быстро обновлять связи интерфейсы и подключать новые через обычный импорт экспорт. И в том числе использовать общие библиотеки.
Я не против микрофронтов, они классные если нам нужно решить проблему с разделением релизов между командами. Но применять их только ради разбиения кода по доменам? Кажется все тоже самое можно сделать и без микрофронтендов, но проще.
Микрофронтенд это часть проекта выделенная отдельно. Более того она даже не обязательно должно быть в другом репозитории и иметь сильную свободу по подходам и архитектуре. Более того, на фронте, в отличии от бэка это приводит к большим проблемам с увеличением бандла и скорости работы приложения.
Нет никакой разницы монореп вы используете или нет, прова код овнера могут быть разбиты по папкам а не по репозиториям.
Вы высказали идею, что переход на микрофронты решит нашу проблему разбиения кода. Но все тоже самое можно получить не разбивая репозиторий на много маленьких, и не организовывая погрузку каждого микрофронтенда отдельно, что приводит к увеличению размера.
С тем же успехом можно сказать что любое разбиение проекта на уровни "вводит дополнительные ограничения и неудобства", но на практике оно необходимо особенно при росте проекта.
я думаю вы не верно ставите соотношение применяемости этого разбиения. Я бы сказал, что наоборот на больших проектах куда чаще разбиение по доменам отлично помокает.
Но вы подняли отличный вопрос: а зачем это на маленьких проектах? Все верно, там это и не нужно, но там будет логично поднять вопрос и про уместность реакта. Ведь реакт это тоже самое - мы инвестируем ресурсы, что бы потом возможно получить бенефит.
то что есть и другие проблемы - не говорит о том, что это решение частного случая - плохое. Более того - хорошо структурированный и понятный проект позволет лучше его понимать, и соотвественно его и рефакторить проще снижая техдол, и от дублирования кода избавлятся, и переосмысливать связи между компонентами. Все эти шаги проще делать при разбиении по доменам. Вы сами указали, что те проблемы, на которые я указывал, хорошо решаются микрофронтами. Если вы рассматриваете микрофронты как адекватное решение которое приносит бенефиты на большой проект, то почему вы так сильно выступаете против разбиения не домены?
а микрофронты в итоге и есть то самое разбиение по доменным областям (с оговорочками). И вот эти оговорочки приводят к тому, что проще и эффективнее работать в рамках одного продукта разбив на домены.
Это не какой-то абстрактный проект. Три моих последних проекта были именно такмими, и только в одном мы делали переход на микрофронты. И этот переход был обусловлен не тем что нужно разбить на домены(это разбиение прекрасно выполняется и без микрофронтов), а тем что хотелось развязать релизный цикл между командами и где каждая команда выполняла релиз отдельно
в итоге в идеальном мире все сведется к или
components/orderhooks/orderи наоборот
order/componentsorder/hooksИ казалось бы в чем разница, ведь меняем шило на мыло? что вам в компонентс искать ключевое слово
order?Но проблема в том, что в одном случае мы явно закрепили домен на самом верхнем уровне, в другом групировка постепенно прорастает, и тут возможны рсхождения. Так же проще отслеживать зависимости из одного раздела, который в явном виде поставляет, что хочет отдать, чем из десятков файлов по одному.увы, но нет. Мало кто нормально поддерживает нормальное именнование подгрупировки синхронизированное между components, helpres ... Да и в принципе это довольно странно:может быть на один домен 30 коммпонентов, и один хук. Что мы будем в этом случае делать? в каждом разделе создавать подраздел по домену? а если не создадим, то нужно будет помнить про то, что для вот этого домена есть хук?
конечно если мы знаем точное имя компонента или знаем как точно его найти - то никакой сложности нет. Но ведь кейсы не все настолько простые? Довольно часто нам нужно вообще посмотреть что уже написанно по определенной предметной области, но точное именование может быть совсершенно разным. На маленьком продукте мы еще можем попробовать пройти все сценарии и попытатся найти подобное. Но на большом это уже затруднительно.
вот вот, казалось бы разбей все сразу на нормальные разделы по доменам и не гадай потом где и что написанно по этой предметной области, но почему-то у некоторых людей жгучее желание свалить это в одну кучу.
похоже обе наши ветки приходят к одному и томуже, поэтому предлагаю переместиться сюда: https://habr.com/ru/companies/doubletapp/articles/870236/comments/#comment_27734634
все верно, когда их становится в "куче" много, их начинают групировать в этой куче. Более того, как правило это приводит и к тому что в других "кучах" так же возникает необходимость групировки.
в итоге у нас
/orderSpecifiedповторяется в нескольких разделах. И самое веселое когда в одном разделе это уже сгрупированно, а в другом нет, и там начинают групировку. Это часто приводит к тому , что появляются расхождения.Идея же групировки по бизнесу разворачивает порядок групировки - вначале идет домен, а уже потом любое удобное разбиение (в том числе и классическое). В таком случае вам сложнее получить разные имена и сразу видно весь функционал по определенной доменной области. Это отсекает разные проблемы от поиска функционала по домену: например
components/cart/...иcomponents/order/...(и попробуй угадай как это назвал прошлый разраб), в то время как уровень ниже уже легко разбивается по любой другой системе со строго определенными разделами.Так же я заметил, что у вас смешаны в кучу бизнес компоненты и инструментальные примитвы. Если мы разбиваем по доменам, то никто не машает нам вынести инструменты общие для проекта в shared. Это позволяет лучше понимать какими инструментами мы обладаем, а не разбираться в мешанине: бизнес/не бизнес.
отлично, то есть у вас оно в глобальное пространство уходит. И как я понимаю компоненты отвечающие за его отображение так же уходят в глобальную папку components?
Это работает в обе стороны. Может это вы не понимаете фсд и о чем говорит ваш собеседник?
Окей. Допустим у вас тысяча страниц и 10 из них использует одну и туже функцию или компонент который завязан на бизнес. Где вы его разместите в данной структуре? У вас из вариантов тольк либо его привязать к странице, либо скинуть в кучу. В первом варианте у вас страница выступает в роли домена, а в другом варианте у вас начинает копиться свалка в общих компонентах, так как вы туда помещаете все общие компоненты по всем доменам.
возмем вашу схему и попробуем разложить несколько хуков привязанных к бизнесу. Допустим хук получения списка товаров активного заказа вы как в этой схеме расположите? Ну или любой другой бизнес хук который может использоваться сразу в нескольких компонентах?
отлично, этот хук не привязан к сущности и складывается в shared.
а вот допустим: hooks/useOrderItems - уже привязан к заказу и его можно положить в домен заказа. Зачем он мне на глобальном уровне, если я использую его только для некоторых компонентов (которые так же привязаны к этому домену)?
Все зависит от размера проекта. Если у вас 20 хуков, то конечно нет ничего плохого в классическом разбиении. Когда их перешагивает за 200? отслеживать то , что уже написано по определенному домену - становится очень сложно
И да, и нет. Классическое разбиение не предлагает хороших решений для проблемы роста числа файлов объединенных по одному типу. Соответственно на больших проектах это приводит к свалкам. Если у вас есть контр примеры, я с радостью их услышу. Но пока весь мой опыт это только подтверждает
Распределение по домменым облостям упрощает поиск и навигацию. Одно дело когда у нас свалены все компоненты в одну кучу, а еще к ним идут свои хелперы, утилиты, хуки, модели, обработчики. В итоге у вас на верхнем уровне доступно сразу все. На более менее большом проекте это приводит к сотням файлов в каждой категории, и делает поиск по ним банально неудобным. Иногда становится сложно даже понять по какому ключевому слову мы можем найти уже написанный код.
В то же время, разбив это в первую очередь по доменам мы сужаем область поиска, так как весь код связанный с определенным функционалом находится в одном месте.
Я не вижу ни одной причины отказыватся от разбиения на домены, ведь из всей принципиальной разницы с классикой мы получаем удобную верхнеуровневую групировку. Конечно в fsd этой разницы больше, но в целом они следуют похожей идее.