Comments 23
Становится сложнее выстраивать структуру большого объёма кода в рамках одного слоя. То есть, среднестатистический разработчик уровня "junior" или "pre-middle", вероятно выстроит архитектуру внутри слоя "pages" хуже, чем с чётким разделением слоёв, задающих свою структуру.
Ключевое слово вероятно. А в реальности, скорее наоборот, внутри слоя "pages" он и любой другой выстроит архитектуру лучше. А вообще в целом FSD подход это шлак. Но в этой новой версии, они хотя бы сделали шаг ан встречи для адекватных людей.
Появляется "дополнительный шаг" при поиске нужного участка кода. Ранее, храня всю логику внутри глобальных "entities", "features" и "wigdets" слоёв
Чаво чаво? Вместо 3 ненужных папок сделали одну, а значит сократили кол-во лишних шагов. А вы говорите дополнительный шаг добавился.
Вся четкая иерархия слоёв, выстроенная до 2.1 версии, фактически "множится на 0", так как польза от её использования появляется только при декомпозиции пере используемой логики, что вероятно, не является частым кейсом при разработке.
Четкая иерархия? Смешно.
Да никто никогда не знает сразу куда запихнуть тот или иной код, а может в entities? А может в features? А может в wigdets? И по факту каждый раз перед разработчиком встает головоломка, в итоге все превращается в убогое месиво размазанное по этим 3м папкам и ты никогда не знаешь сразу куда пойти чтобы найти то, что тебе нужно.
А 2.1 это наоборот шажок в сторону классической архитектуры нормального человека, где никаких проблем нет и не может быть, вне зависимости от того, маленький у тебя проект или гигантский. Ибо там всё максимально очевидно, просто и наглядно.
На что можно заменить "pages first"?
Так же как и FSD в целом выкинуть в урну и вернуться к классическому подходу. А не выдумывать проблемы самому себе и пытаться их решить жалкими способами.
Чем плох "легальный" кросс-импорт?
Начнем с того, что кросс-импорт вообще не плох, а очень удобен. А если вы не умете с ним работать, то это сугубо ваши проблемы.
Это все равно что отказаться от классов в пользу функций. Или от функций в пользу классов. И т.д. и т.п. все подходы хороши и нужно брать лучшее из каждого и пользоваться, а заковывать себя в кандалы, отказываясь от чего-то и плакать.
В Вашем комментарии много заявлений и мало аргументации.
1. Говоря о том, что любой разработчик выстроит архитектуру внутри pages грамотнее, чем с чётким разбиением по слоям, хотелось бы видеть небольшой пример того, как бы Вы сделали это сами. Не уверен, что результат был бы оптимален.
2. В абзаце про "дополнительный шаг" я написал, почему считаю, что он появляется, так как появляется неочевидность в вопросе местонахождения того или иного модуля. Вы уверены, что дочитали абзац до конца?
3. Согласен с тем, что бывают проблемы с тем, в какой слой (entities, features или widgets) положить модуль, однако не вижу проблемы в том, чтобы единожды договориться об этом внутри команды и следовать договорённости.
4. Видно Ваше неприятие в сторону FSD и симпатию к некой "классической" архитектуре. Это очень размытое понятие, хотелось бы конкретики, что для Вас хорошая архитектура.
5. Очевидных плюсов использования кросс-импортов лично я не вижу, зато вижу минусы, о которых и написал в статье. Хотелось бы узнать, каковы же плюсы использования кросс-импортов на ваш взгляд, ведь даже разработчики FSD в документации рекомендуют максимально их избегать.
Хотелось бы узнать, каковы же плюсы использования кросс-импортов на ваш взгляд, ведь даже разработчики FSD в документации рекомендуют максимально их избегать.
А если они скажут что есть и пить это плохо, да и спать тоже, что тогда?
Вы понимаете что апеллировать к "авторитетам" это прям скажем странно. Ибо во первых они авторитетами даже близко не являются, во вторых это не точные науки, где 2 + 2 = 4 и это можно легко проверить и однозначно в этом убедиться.
А плюсы же очевидны и просты, если модулю A нужно что-то из модуля B, ты просто берешь это и всё. Даже если A <--> B имеют зависимость друг от друга, то все решается просто, зависимости не должны вызываться синхронно в момент инициализации, достаточно сделать setTimeout и все. А если в момент инициализации синхронно никто никого не дергает, а дергает в процессе, то тем более никаких проблем.
к некой "классической" архитектуре
Ну она же на то и классическая, что вполне себе стандартная на уровне интуитивных вещей. Базовый вид:
src/
components/
Button/
index.tsx
styles.scss
config/...
constants/...
globalState/
userState/
index.ts
helpers/...
lib/...
hooks/...
layouts/
mainLayout/
index.tsx
styles.scss
authLayout/...
routes/...
pages/
login/
index.tsx
state.ts // Локальный стейт страницы
styles.scss
items/
components/
component1/
index.tsx
state.ts // Локальный стейт компонента
styles.scss
component2/...
index.tsx
state.ts // Локальный стейт страницы
styles.scssДальше уже в зависимости от проекта, от уровня разраба и т.п. Заметьте, тут даже никакие пояснения не нужны, никакие договаривалки и изучение. Всё предельно понятно на интуитивном уровне.
Согласен с тем, что бывают проблемы с тем, в какой слой (entities, features или widgets) положить модуль, однако не вижу проблемы в том, чтобы единожды договориться об этом внутри команды и следовать договорённости.
Да ладно? Прямо заранее все все все вариации и кейсы обсудили и договорились да? И ещё где-то записали. И память прям у всех идеальная. Прям реалистичность зашкаливает. А теперь вернемся в реальность, разработка это не черное и белое, там 100500 вариацией и плетеней, зависимостей, сайд эффектов и т.п. Об этом нельзя договориться, поэтому на каждый чих ты думаешь а куда же это положить ту или иную фигню, ведь мы же такие умные и выбрали FSD (Freaky Sliced Design), а теперь страдаем.
Ну и опять же к чему все эти сложности на ровном месте? Когда на самом деле все предельно просто.
1. Конечно же бывают споры о том, куда положить модуль и после того, как команда это обсудила. Я имею в виду, что после обсуждения, БОЛЬШИНСТВО вопросов о том куда положить модуль исчезнут сами собой. Большинство не равно все, так как мы не живём в идеальном мире.
2. Касательно предложенного вами варианта структуры проекта. Если речь идёт о небольшом приложении, такая структура вполне жизнеспособна и выглядит даже лучше, чем FSD, однако если мы возьмём банальную ситуацию в которой вам нужен для нескольких страниц одинаковый, достаточно большой кусок логики (например какая-нибудь форма заказа), окажется, что либо придётся копипастить код между страницами, либо кросс-импортить компоненты между страницами, либо раздувать components большим количеством компонент.
3. Решение зависимостей через SetTimeout выглядит слегка костылём, когда других вариантов не нашлось.
4. Не совсем понимаю, о каких сложностях идёт речь. FSD концепции довольно просты для понимания. Если методология отступает от концепций очевидного наименования логики, она сразу становится нежизнеспособной?
однако если мы возьмём банальную ситуацию в которой вам нужен для нескольких страниц одинаковый, достаточно большой кусок логики (например какая-нибудь форма заказа), окажется, что либо придётся копипастить код между страницами, либо кросс-импортить компоненты между страницами, либо раздувать components большим количеством компонент.
Не понял вообще проблемы, ну есть у вас общая логика, вынесете ее в виде отдельного компонента в src/components/MainForm и все, на всех страница где нужна эта форма берите ее. Это же интуитивно понятно.
Решение зависимостей через SetTimeout выглядит слегка костылём, когда других вариантов не нашлось.
Костыли костылям рознь. Есть безобидные, а есть жесткие. Либо максимальное удобство, и безобидный setTImeout либо изворачивайся через специальные модули агрегаторы и т.п.. По мне setTImeout выигрывает по всем фронтам ибо не несет когнитивной нагрузки, не усложнят код и т.п.
Не совсем понимаю, о каких сложностях идёт речь. FSD концепции довольно просты для понимания
entities, features, widgets вообще прям все "просто" и "понятно" и голову ломать не надо каждый раз, ага. И прям "легко" по коду проекта искать то, что тебе нужно. Вместо того что страницу положить в ее законное место, мы будем разность ее по частям по разным папкам. Ну бред же.
Если методология отступает от концепций очевидного наименования логики, она сразу становится нежизнеспособной?
В данном случае да. Она изначально была нежизнеспособная. Причем чтобы это понять, не надо было даже ее на реальном проекте применять, достаточно было просто провести мысленный эксперимент.
Касательно предложенного вами варианта структуры проекта. Если речь идёт о небольшом приложении, такая структура вполне жизнеспособна и выглядит даже лучше, чем FSD
Какая разница небольшое приложение или огромное? Она одинаково интуитивно понятна всегда. В этом и смысл делать все так, чтобы было интуитивно понятно.
Я понимаю и принимаю Ваш ход мыслей. Вопрос о идеальной архитектуре скорее риторический, и продолжая диалог мы вряд ли изменим мнения друг друга.
Вопрос о идеальной архитектуре скорее риторический
Верно, просто я не вставляю палки себе в колеса и всё) И не понимаю тех кто вставляет) Разумеется вкусы у всех специфичны, кому то подавай велосипед с круглыми колесами, кому-то с квадратными. Те, кто предпочитают квадратные, не понимают как можно ездить на круглых и наоборот.
1. Говоря о том, что любой разработчик выстроит архитектуру внутри pages грамотнее, чем с чётким разбиением по слоям, хотелось бы видеть небольшой пример того, как бы Вы сделали это сами. Не уверен, что результат был бы оптимален.
Разумеется он был бы оптимален, всё просто. Я предлагаю идти ногами вперед, и это интуитивно понятно для всех людей, для этого не надо быть гением. А вы предлагаете ходить задом наперед, ещё и ноги под неестественными углами ставить. Как думаете кто пройдет дальше, быстрее и легче? Думаю ответ очевиден.
2. В абзаце про "дополнительный шаг" я написал, почему считаю, что он появляется, так как появляется неочевидность в вопросе местонахождения того или иного модуля. Вы уверены, что дочитали абзац до конца?
Дочитал. Но вы сами написали ерунду, фейковый "аргумент". С чего вдруг в "pages first" страница будет лежать в "entities/blog/ui/BlogPost"? Это же в высшей степени противоестественно. У нее единственный вариант, лежать в папке pages. Поэтому в случае в pages first никаких доп шагов быть не может, в поиске страниц по крайней мере.
Но всё равно FSD всё ещё непригодна к использования, да и никогда не будет пригодна. Задумка изначально противоестественная.
Всё уже придумано давно на интуитивном уровне(это я про классическую архитектуру) и варианта лучше просто объективно нет.
Новый подход "pages first" - это переизобретение колеса
Наконец-то, спустя года, переизобрели дошли до так называемого "page first" подхода, который является интуитивным и классическим) Если честно, на крупных проектах FSD - ооочень плохая идея. Он не является интуитивно понятным и логичным, каждый его еще и переделывает под себя. В итоге получаем просто монстра, с которым не понятно, как работать. А для того, чтобы убедиться, что этот подход не очень, достаточно зайти на сайте FSD в раздел с примерами и увидеть, что даже в маленьких проектах все не то, чем кажется, да и сами проекты нарушают теже самые правила FSD.
Для стандартизации правил FSD существует линтер Steiger. Если разработчики его не используют, вопрос скорее к ним, нежели к команде разработки архитектуры.
По поводу использования FSD в крупных проектах, могу предложить как вариант монорепу с N-ным количеством небольших FSD приложений и разрулить потом всё через, например, ModuleFederationPlugin в сборщике.
По поводу использования FSD в крупных проектах, могу предложить как вариант монорепу с N-ным количеством небольших FSD приложений и разрулить потом всё через, например, ModuleFederationPlugin в сборщике.
Oh my dear god... куда катиться этот мир. Неужели мы обречены
Для стандартизации правил FSD существует линтер Steiger. Если разработчики его не используют, вопрос скорее к ним, нежели к команде разработки архитектуры.
Так дело не в линтере) Я могу полный бред написать, напихать в папку core или libвсякой ерунды и линтеру, само собой, будет ок) Разговор про простые интуитивные правила, которые в FSD очень легко нарушить
По поводу использования FSD в крупных проектах, могу предложить как вариант монорепу с N-ным количеством небольших FSD приложений и разрулить потом всё через, например, ModuleFederationPlugin в сборщике.
извини, но это антипаттерн) делать крупный проект через монорепо - уже плохая идея, но делать это для натягивания fsd - за гранью)
Тут не согласен с "крупный проект через монорепо - уже плохая идея". Скорее делать через микрофронты - плохая идея. В архитектуре, где каждая страница - независима и загружается асинхронным чанком, до 50 страниц не будет проблем. Потом может понадобиться вынести "страница и связанные с ней 10 страниц" в отдельный пакет, разрабатываемый отдельной командой, но это хорошо ложится в монорепо, и плохо ложится в микрофронт.
Я не про fsd сейчас, просто зацепился за сам концепт)
Разумно. Микрофронты были предложены как первый пришедший в голову вариант. Хотя, конечно, не единственный.
В архитектуре, где каждая страница - независима и загружается асинхронным чанком, до 50 страниц не будет проблем.
смотря как выглядит микросервисная архитектура. Я говорю про проекты по типу яндекс маркета или озона. там монорепо с FSD = самоубийство) начиная от разработкти и заканчивая релизом)
"получаем просто монстра, с которым не понятно, как работать" - возможно это и цель. На Хабре очень много статей про то, что "не сделаешь баг - долго не проработаешь", "не сделаешь сложный код - станешь заменим". Это даже пыталось стать трендом, и ряд проектов специально берет нишевые подходы, чтобы долго думать что такое виджеты, энтити и фичи, хотя ни в бизнес-требованиях, ни в логике приложения этого нет.
Я безусловно за классическую структуру проекта, так же как и за семантическое отношение к написанию кода - они должны быть читаемыми и логичными, как предложения, и так же логично располагаться в проекте. Но по сложно понимаемым причинам ряд разработчиков идет сложным путем, возможно как раз из-за "авторитетности" мнений и выбирает даже Redux или что похуже.
Где найти пример классической архитектуры для больших проектов?
Где найти пример классической архитектуры для больших проектов?
Вот же https://habr.com/ru/articles/867232/comments/#comment_27683716
Спасибо, что подсветили тот факт, что мы забыли добавить информацию о публичном АПИ для кросс-импортов (`@x`) в ченджлог! Обновили его :)
Спасибо и за мнение о новом подходе. Я с ним, впрочем, не согласен (думаю, неудивительно :) ), главным образом по причине того, что долгое время наблюдал, как много проблем у людей возникает из-за различающегося понимания того, что такое сущности и фичи. Ваше предложение о том, как распределить код по слоям, имеет место, но это лишь ваше мнение, и велика вероятность, что даже внутри одной команды найдется иное мнение. При этом на страницы делить умеют почти все, и бОльшая часть преимуществ FSD вполне доступна даже с тремя слоями Shared, Pages и App. Так что если есть возможность избавить большинство людей от лишней головной боли, мы этой возможностью воспользуемся.
Добрый день. Конечно. Статья является лишь моим субъективным мнением о том, какой ещё вариант можно применить, но не является руководством к действию) Касательно кросс-импортов, в документации несколько месяцев висит pull request со страничкой под этот раздел. После выхода 2.1 он уже, наверное, не полностью актуален, однако хотелось бы, чтобы ревью было проведено =)
FSD 2.1 или как «pages first» подход может ухудшить структуру ваших Frontend приложений