Комментарии 44
Совет №1: старайтесь вести разработки именно в таком порядке — от сущностей до страниц. Не надо пихать весь код кучей в
pagesи потом пытаться это оптимизировать.
Это плохой совет. Оптимизировать структуру нужно там где это требуется. Если не знаете куда кидать компонент, лучше начинать с widget. Иначе будете тратить силы постоянно на размышления о том куда что запихать. FSD оч сильно тормозит скорость разработки если слишком запариваться, а профиты от декомпозиции со временем кажутся не такими очевидными.
/features в FSD по факту это недопапка. Потому что кроме экшен кнопок вы там вряд ли что либо будете хранить. Возьмём например крупную фичу которую бизнес решил добавить в приложение: визуальный редактор аватара пользователя. это фича или виджет?) для бизнеса это точно фича. Но пихать столько всего в папку фичи вы не будете. Тут идёт противоречие с бизнес моделью которое всех будет вводить в замешательство.
Возможно, Вы и правы. Спасибо за эту ремарку. В конце концов мы и сами только в начале знакомства с FSD.
Мне на самом деле сделали это же замечание буквально вчера, но я решил все же не править статью. Поясню за свои слова: на мой взгляд это все же зависит от специфики коллектива, навыков разработчика и требований бизнеса. При подходе "сверху вниз" на мой взгляд есть шанс скатиться в ситуацию, когда весь код накидан в спешке в page, проверен на работоспособность и отправлен на прод с надеждой в будущем это разобрать и отрефакторить. И вот этот самый рефакторинг не у всех случается. И вся идея FSD идет на смарку.
Если же двигаться снизу вверх, то вы чисто физически не нарушая законов FSD не сможете все разместить в entities. Вам придется что-то поднимать на более верхние уровни так или иначе.
Да, соглашусь, что это может тормозить скорость разработки, но это можно отнести ко многим методологиям. Да даже одним из минусов Typescript считается увеличение времени на разработку, но давайте будем честными, это меньшее из зол.
Это простой (пока что) личный кабинет для управления процессами
В этом-то и проблема. На простом фронте любая архитектура структура папок будет выглядеть неплохо.
Соглашусь)) Но писать сложный проект вообще без методологии еще хуже, наверное
Я участвовал в разных проектах, на React+TS пишу уже 8 лет. По разному пытались строить архитектуру. Лично по моему опыту, FSD пока что лучшее из того, что я пробовал. Как минимум имея уже с десяток страниц в проекте (я в статье не все расписал, само собой), нет ощущения, что что-то не вписывается в эту структуру.
Ну хорошо, десяток страниц. А если страниц 1000? Для десятка страниц средней сложности любая структура подойдёт, как мне кажется.
На мой взгляд число проектов в 10 страниц кратно превышает число проектов в 1000 страниц. Я бы сказал, даже, что немного сомневаюсь, существуют ли такие приложения, на 1000 страниц)) Ну это просто про релевантность проблематики вопроса.
Само собой, на такой сложности проект стоит проектировать что-то свое ибо это вовсе не банальная задача. Но, собственно, и документация FSD об этом говорит, что данная методология вовсе не панацея, но для многих она может быть очень даже полезной. Вы с этим не согласны?
"Отвергаешь - предлагай". Хотелось бы у знать Ваши предпочтения, что бы вы посоветовали, в качестве альтернативы для приложения среднего масштаба. Мы же здесь для обмена опытом и знаниями, не правда ли? ))
Да, верно
Вот мне в FSD не понравилось то, что надо задумываться о правильности структуры, о правильности испортив и т. д.
Я бы сказал, что серебряной пули не существует. Где-то вообще может подойти чистая архитектура, но это больше для мобильных приложений, скорее.
А так - всё зависит от проекта. Можно иметь подобие FSD, но, честно говоря, она выглядит переусложненной и, как мне кажется, не очень масштабируемой, так как структура плоская получается и рано или поздно у нас будет очень много слайсов в том или ином месте.
В последнее время предпочитаю фрактальную архитектуру, но и это не панацея)
По личному опыту, с импортами не вижу особых проблем, если честно. По началу было боязно, но как говорится, глаза бояться, а руки делают. Пока что было всего пара "узких" места, которые решились довольно легко.
А по поводу обилия слайсов тоже есть выход - fsd допускает их группировку (зря про это не написал в статье, кстати...) Поэтому можете группировать их как вам душе будет угодно и никакой плоскости не будет. Про глубину вложенности группировки я не уточнял, но мне кажется никто вас пинать не будет, если вы решите её делать многоуровневой
>отсутствие формализованной методологии
Когда входят новые разработчики, вы даете документацию к методологии? или вы описали это в рамках своей документации?
Если даете просто линк на сайт, то люди будут сталкиваться с тем, что все по разному понимают сущности в FSD и страдают
И вопрос про масштабируемость, а как вы ощущаете/понимаете, что ваша прошлая архитектура не могла масштабироваться? с какими проблемами столкнулись?
>отсутствие формализованной методологии
В контексте моего приложения документации не было вообще. На словах обсудили и пошли писать код. На данном проекте нас полтора землекопа, поэтому отложили этот момент на будущее, что не есть идеально. На других проектах, где я работал было что-то подобие свода правил. Иногда было подробно расписано, иногда не очень. Но во всех случаях не было такой подробной документации, как у FSD.
Конечно разночтения могут быть и будут, но тоже самое можно сказать и про другие проекты, где мы писали без FSD. Приходит новичок, ты ему что-то объясняешь, а он все равно делает по своему. И такая картина первый месяц или даже три, в зависимости от грейда. Это обычное дело. Но имея на руках документацию, наверное будет проще построить процесс "вливания" в коллектив, нежели без нее.
По масштабируемости - самая главная проблема с чем сталкивался это необходимость выносить модули, в основном модели, иногда представление списков, в common. То есть деление раз шло изначально отталкиваясь от бизнес-сущностей, если точнее от страниц, то и модели были как бы закреплены за этими страницами. И когда модель начинала учавствовать в других "страницах" то вставал вопрос - либо прибегать к кросс-импортам, что уже на подсознательном уровне не очень красиво, хоть мы такого правила не устанавливали. Либо выносить эту модель в Common. И Common со временем начинал расти и превращался в свалку.. его приходилось делить на какие-то выдуманные разделы: UIkit, lib, helpers, utils..
Имея за плечами n количество проектов, в том числе пару на fsd, так и не понял в чем его профит. История этой штуки выглядит как "мы изначально сделали плохо, потом попытались полностью переделать и стало чуть получше, но все равно сложно". Лично я считаю, что хорошая структура, это когда новый разраб через пару дней уже может делать новые фичи, с фсд так не работает.
Ну например когда есть папка components и utils это получается идеальная структура проекта? Ведь с такой структурой любой джун сможет с первого дня начать пилить новые фичи
Не очень понятно из Ваших слов, что значит "через пару дней может делать фичи".
Если в вашем коллективе допускается, что через пару дней новичка можно выпустить в свободное плавание и пусть делает как хочет, то это скорее свидетельствует о низких стандартах качества кода и фривольности в разработке, чем о грамотности архитектуры. На мой взгляд ни одна, подробно описанная методология/архитектура не способна дать такой быстрый вход. Если в коллективе есть определенная культура, то любого новичка независимо от грейда приходится направлять и помогать адаптироваться минимум месяц, ибо все приходят со своим багажом знаний и мыслей на счет того, как должен писаться код.
Если речь о том, что новичку придется изучать одну только методологию два дня, что бы приступить к разработке, то это не так. Я вообще не вижу проблем разобраться в ней за пару часов с хорошим ментором. В FSD нет абсолютно ничего сверхъестественного. Она не сложнее, чем любая другая методология, по которой я работал, будь-то фрактальная, или container/components/state/api/etc или др.
Если в вашем коллективе допускается, что через пару дней новичка можно выпустить в свободное плавание и пусть делает как хочет, то это скорее свидетельствует о низких стандартах качества кода и фривольности в разработке
Наверное тут стоит уточнить, что новичок - это именно новый член команды, а не джун или стажер. Не совсем понял про свободное плавание, есть код ревью и командный код стайл. Фронт разраб через пару дней уже может начать красить кнопки и менять шрифты, не вижу тут какой то проблемы. Возникающие вопросы обсуждаются на созвоне с лидом, всё как обычно, и так было абсолютно во всех коллективах, от стартапов до энтерпрайзов и финтехов, на качество никто не жаловался.
В FSD нет абсолютно ничего сверхъестественного.
Я рассказываю про свой субъективный опыт и не претендую на истину. Я сидел с документацией и выступлениями авторов больше двух недель и пришел к выводу, что данная концепция вносит больше проблем и неопределенностей, даже если вынести за скобки то, что каждому члену команды придется изучить дополнительный уровень абстракций.
Организация файловой структуры в рамках используемых технологий фреймворков и сборщиков призвана упрощать разработку, в идеале чтобы каждый интуитивно понимал что за что отвечает, и получал удовольствие от разработки, а не ежедневный батхёрт на код ревью от споров с коллегами по поводу концепций.
Также является показательным, что вам уже на старте приходится отклоняться от правил и принимать некоторые допущения, натягивать концепцию на фреймворк. Любая стандартная файловая структура легла бы без этой головной боли.
В общем спустя время ждем честный фидбек, пока выглядит как работа ради работы.
Видел я пару проектов без структуры. В одном проекте за три года кода наросло много, конечно разбито на некоторые модули и новые фичи добавлять вполне возможно, но вот что касается правок это было сложно.
Я думаю знание fsd и опыт работы с ним даёт некое понимание как лучше структурировать проект. Когда приходишь на новый проект то сразу замечаешь что заложена какая то структура и с ней гораздо проще разобраться, если конечно не на месяцок зашёл))
FSD — это, пожалуй, то, чего так не хватало в Frontend-мире.
Пожалуй здравый смысл - это, то, чего так не хватает в Frontend-мире. Люди до сих пор используют Redux / RTK, или того хуже, всякие RxJS, Effector'ы, Zustand'ы и т.п. А некоторые вообще идут дальше и в принципе стейт менеджер не используют, использую чисто встроенные в реакт средства.
А FSD это очередная мимолётная чупуха, которая фактически приносит на 90% головную боль и геморрой и лишь на 10% пользу.
На мой взгляд сравнивать методологию с библиотеками крайне странно... любая библиотека плоха тем, что разработчику приходится вписывать свое приложение в её ограничения. И если что-то тебе в библиотеке не нравится есть всего три варианта:
попросить разрабов внести правки / принять твой пулл-реквест.
сделать форк и использовать свою версию либы, с необходимостью вручную её обновлять и править конфликты.
смириться и писать костыли.
Методологии хороши тем, что ты не ограничен в их использовании и применении. Методология - это лишь свод рекомендаций. Ты можешь её использовать частично, можешь её изменить под свои требования. Если для специфики вашего приложения FSD - это всего 10% пользы, то вы вправе применять FSD только на 10%. В методологии же главное - э то не код, а принципы его реализации.
Ну и про мимолетность: Agile-методололгии никуда не ушли. БЭМ никуда не ушел. Даже TDD вполне жив и применяется. У меня подозрение, что FSD тоже имеет все шансы прижиться в том или ином виде, ибо ничего настолько формализованного просто напросто еще не существует. Вакантное место совершенно пусто.
На мой взгляд сравнивать методологию с библиотеками крайне странно...
На самом деле сама суть была во фразе из статьи:
FSD — это, пожалуй, то, чего так не хватало в Frontend-мире.
Т.е. это преподносится как прям глоток свежего воздуха и Game Changer в мире Frontend'a. Но фактически, положительный импакт от FSD на столько минимален(в реальности скорее перевес в пользу отрицательного, по сравнению с традиционными подходами здравого смысла) что это про очередная аббревиатура которая появилась, но толку от нее нет.
А если вернуться к аналогии с библиотеками, то на примере того же React'a когда появился MobX, это был реальный очень сильный положительный импакт и Game Changer.
Т.е. если сравнить влияние на Frjntend, то эта библиотека улучшает жизнь в реальности на 98 из 100, а FSD если даже улучшает(в реальности скорее либо на том уровне всё остается в лучшем случае, а чаще хуже), то от силы это будет на 5 из 100. Поэтому вот эта фраза в статье о FSD это смешно)
Увы, но Вы не так трактуете мои слова.
Во первых я не соглашусь с Вашим мнением о бесполезности FSD. Вы же, очевидно, её даже не пробовали, не знаете плюсов и не знаете минусов. Не очень тактично делать заявления обладая нулевым опытом. Если я не прав, то прошу прощения! Но тогда хотелось бы от Вас услышать развернутый ответ, с какими трудностями Вы столкнулись в работе с FSD, чем она вам так не прельстила? Все же продуктивнее обменяться опытом, чем переливать из пустого в порожнее.
А во вторых. Я говорил именно о том, что FSD своего рода "закрыла гештальт". Во Frontend-мире с момента популяризации SPA появилось очень много всего. Но не было именно грамотной, продуманной методологии. Были десятки (если не сотни) стейт-менеджеров, сборщиков пакетов, эффект-менеджеров, API-клиентов, css-процессоров, видов роутинга и инициализации проекта. А вот архитектурных методологий такого уровня, с такой детализации - нет. Пусть это и не GameChanger, но это серьезный шаг в сторону ответа на вопрос, который разработчики всегда решали сами у себя на коленке.
Во первых я не соглашусь с Вашим мнением о бесполезности FSD. Вы же, очевидно, её даже не пробовали, не знаете плюсов и не знаете минусов
На самом деле тут всё просто, есть традиционная классическая структура фалов/папок/вложенностей аля здравый смысл и удобство:
Так вот, я попытался себе ответить на вопрос, чем FSD будет лучше/удобнее/быстрее в разработки чем классика, Ни в совокупности это ничем не лучше классики. Плюс у меня был проект на котором уже FSD, и приходилось много лишних телодвижений делать чтобы найти нужные места в коде, плюс тратить лишнее время на подумать а в какую же папку положить то или иное, в общем всё что на выходе мы получаем это трата extra time впустую. Плюс у меня есть друзья разработчики которые так же пробовали FSD и реальных плюсов не обнаружили, только сталкивались с проблемами и придумывали костыли для того чтобы вписываться хоть как-то в FSD. В итоге FSD это просто избыточное дробление, которое реально избыточно в 99% случаев, а это накладывает постоянные неудобства и увеличение времени разработки.
Но может быть вы мне ответе чем реально лучше FSD классической схемы что я привет выше на скрине, и если если реально по совокупности всех факторов она окажется удобнее, быстрее в разработке и т.п., то я с радостью буду ее применять. Так вот вопрос, чем FSD реально лучше чем мой пример?
А во вторых. Я говорил именно о том, что FSD своего рода "закрыла гештальт"
Да вот нет, ибо он уже много лет как закрыт классическим способом, пример выше.
Были десятки (если не сотни) стейт-менеджеров, сборщиков пакетов, эффект-менеджеров, API-клиентов, css-процессоров, видов роутинга и инициализации проекта.
Как раз таки они оказывали ключевое влияние на жизнь проекта, а не структура файлов и папок.
А вот архитектурных методологий такого уровня, с такой детализации - нет.
Да потому что архитектура и так на интуитивном уровня понятна любому разработчику у которого есть опыт. Плюс в каждом конкретном проекте эффективна именно архитектура с учетом специфики конкретного проекта. А все решения которые обобщенные, увы и ах не канают. Всегда всё индивидуально.
Пусть это и не GameChanger, но это серьезный шаг в сторону ответа на вопрос, который разработчики всегда решали сами у себя на коленке.
Ну опять преувеличение невероятного масштаба. Дополнительное избыточное дробление это конечно офигеть шаг) Вот просто вопрос, например какой реальный плюс разделять model и api?
Ну вот например слитно:
export class ItemsPageState {
items: IItem[] = []
constructor() {
makeReactive(this);
}
fetchItems = async () => {
const response = await new ApiReq(`GET /api/v1/items`).send();
this.items = response.items;
}
}И даже если тут будет ещё 5-10 функций дергающих АПИ, это ни как не ухудшает читаемость/восприятие и т.п. ибо оно к этому относится и лежит рядом.
Спасибо за развернутый ответ. Прошу прощения что пропал - не хотелось отвечать на бегу..
Давайте по порядку. Пример выше очень не плох для очень маленького проекта, как в примере. Об этом и документация FSD говорит. Для одностраничного приложения нет смысла так заморачиваться. Если проект все же крупнее вашего примера, то неизбежно будет расти беспорядок в этих папках. Беспорядок будет заключаться в высокой связности. Так как в данной структуре нет никаких ограничений на импорт модулей, то рано или поздно всё начинает зависеть от всего. И нет возможности внести правки не поломав функционала на других страницах. Мы такой же структуры придерживались на проекте, который в итоге вырос в итоге до 20 или 30 Мбайт исходного кода. Поддерживать это было очень сложно. Это на мой взгляд одна из самых плохих архитектур, которую масштабировать очень и очень сложно.
По поводу "закрыл гештальт" - суть именно в том что FSD формализована. Она описана и аргументирована. Архитектура выше - классическая, но она нигде не описана и не задокументирована. Если у кого-то возникают трудности, то совсем некуда обращаться и не с чем сравнить. Каждый разраб будет принимать решение на основе своего предпочтения, которое может быть весьма недальновидным. В противовес этому FSD дает четкие ответы на большинство вопросов, а в случае частных моментов - есть чат, где можно спросить совета у грамотных людей. И это огромный плюс на мой взгляд.
Вот просто вопрос, например какой реальный плюс разделять model и api?
Да бог с Вами не делите. Никто не заставляет. Состав сегментов не регламентирован FSD. Цитирую доку:
Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей
В моем случае деление на model и api неизбежно, потому что мы используем Redux, а он не допускает хранения несериализцемых данных. Если вы не пользуетесь Redux, вы можете все сложить в models или какой-то другой сегмент, на ваше усмотрение.
Основной принцип FSD не в "излишнем дроблении", а больше в том, что бы выстроить иерархию слоев и запретить хаотичных импорт, который повышает связность проекта.
Второй плюс, который дает FSD - легкий перенос функционала из одного проекта в другой. Надо лишь перенести несколько слайсов из 4-5 слоев. В случае с вашей архитектурой, надо будет бегать по файликам и копировать код буквально кусками - это знаем, проходили.
Пример выше очень не плох для очень маленького проекта
С чего бы вдруг? Он прекрасно применяется на проектах любого масштаба, даже на огромных монолитных. Если у вас не получилось/не получается, это не значит что у остальных тоже.
Если проект все же крупнее вашего примера, то неизбежно будет расти беспорядок в этих папках.
Вы называете беспорядком растущее количество страниц, общих компонентов, глобальных состояний? Ну тогда как бы всё ясно понятно))) В таком случае по вашей логике в любой библиотеке беспорядок, там много книг на полках.
Беспорядок будет заключаться в высокой связности.
Спешу напомнить, это фронтенд, а не бэкенд. Высокая связанность - это то, что неизбежно в любом проекте из реального мира, и это вовсе не минус, это особенность, с которой просто нужно уметь обращаться. опять же, если вы не умеете и для вас это проблема, то это сугубо ваша проблема, а не всех остальных.
Так как в данной структуре нет никаких ограничений на импорт модулей
В это и заключается огромнейший плюс, т.к. это максимальная гибкость, максимально удобство разработки и комфорт, плюсом разумеется скорость. Опять же, если вы любите когда вы всегда во всем ограничены, то вам скорее всего лучше будет в местах не столь отдаленных)) Там как раз таки вполне себе понятные ограничения) Если вы не умеете работать когда вам дана свобода эффективно и раскрывать её потенциал по полной, то это опять же сугубо ваши проблемы, а не всех остальных.
И нет возможности внести правки не поломав функционала на других страницах.
Серьезно? У вас весь мир делится только на черное и белое? Открою тайну, опять же в реальной жизни примерно 99% таких правок люди осознают что они делаю и ничего не ломают. Но бывают крайне редкие кейсы когда что-то может пойти не так, но увы ваш FSD вообще от этого никак не застрахует. Там все те же особенности и проблемы, просто файлов и папок в несколько раз больше.
Мы такой же структуры придерживались на проекте, который в итоге вырос в итоге до 20 или 30 Мбайт исходного кода. Поддерживать это было очень сложно. Это на мой взгляд одна из самых плохих архитектур, которую масштабировать очень и очень сложно.
Поздравляю, легаси длиною в 10 лет, даже 5 лет - это всё, мертвый плохо поддерживаемый проект. При чем тут структура файлов и папок??? Если в нем устарело всё, как технологии, так и подходы к разработке и написанию кода в целом. Оглянитесь назад на 5 лет. Вы писали и думали по другому. Опять же "аргумент" из разряда ну надо же хоть что-то придумать эдакое. Ну и всё так же, если вы наговнокодили дерьмовую архитектуру и т.п., то это сугубо ваши проблемы. А то, что вы говнокодите это я уже понял факт, т.к. вы используете Redux до сир пор, это уже даже не смешно.
Архитектура выше - классическая, но она нигде не описана и не задокументирована
И что? Она интуитивно понятна вообще всем. Ее описание будет выглядеть так - вот смотрите, вы ящик с надписью книги? Правильно, там лежат книги. Вы видите ящик с надписью вилки? Правильно, там лежат вилки. Вы же нигде не описываете и не читаете то, как дышать, вы просто дышите и всё. Так же и тут. Она такая же очевидная, как использование MobX в паре с реактом, а не убожество из прошлой цивилизации в виде redux.
а в случае частных моментов - есть чат, где можно спросить совета у грамотных людей
Которые называют беспорядком растущее количество страниц, общих компонентов, глобальных состояний? Или используют redux в связке с react'ом? Ахаха, ну уж нет, спасибо, пожалуй откажусь)
Основной принцип FSD не в "излишнем дроблении", а больше в том, что бы выстроить иерархию слоев и запретить хаотичных импорт, который повышает связность проекта.
То есть дать 0 реальных преимуществ и на ровном месте усложнить проект введя ряд ограничений и уровней абстракций. Браво, заставлять себя(и остальных) страдать это так весело(наверное).
Второй плюс, который дает FSD - легкий перенос функционала из одного проекта в другой. Надо лишь перенести несколько слайсов из 4-5 слоев. В случае с вашей архитектурой, надо будет бегать по файликам и копировать код буквально кусками - это знаем, проходили.
Да что вы говорите? Серьезно? Если речь про ваш говнокод, то может быть. Самое геморойное что я когда-либо переносил из проекта в проект заняло не более 1 часа. А в 99% случаев это копипаст папки с нужным компонентом и всё. Или копи паст конкретно функции/класса и всё. Более того, потребность такого рода переносов возникает примерно крайне редко. Но вы конечно же сделали из этого целую трагедию, конечно скопировать 1 папку в которой есть всё это намного тяжелее чем несколько слайсов из 4-5 слоев(говоря про FSD, это кстати очередное подтверждение бредовости данной "архитектуры"). Копировать 4-5 слоев чтобы перенести компонент, это уму не постижимо. Ну реально, это же смешно и абсурдно.
зачем использовать next.js для личного кабинета? как я понял, все его фичи скрыты за авторизацией, соответсвенно пре-рендер никакой не нужен
Так они об этом и не думают, да и не только об этом. Просто с пеной у рта берут next.js, redux и прочую дичь ни думая ни о чем. Единственно о чем они думают, что наверное они умные, они ведь видят упоминание в интернете о next, fsd и т.п., а раз упоминания есть, значит это "обязательно хорошо и нам надо".
Причин две:
Это условие свыше, из бизнес процессов. У нас много проектов, и было принято решение сохранять единообразие, для более простого вхождения новичков на проект.
Вторая - у личного кабинета есть еще и публичная часть, в том числе и промо-лендинг. Да, звучит возможно странно. Изначально это были разные проекты, но позже стало выгодно их объединить, так как они стали делить один и тот же функционал.
То есть все остальные проекты тоже на next.js? Я в vk тоже работаю, у нас такого нет.
А новичкам куда проще с react, не все же знают next.js, он довольно прост с pages структурой, но когда app появляется, там идет куда более тонкая настройка, что будет серверным и клиентским. Pages со временем по любому устареет и останется legacy с дорогой поддержкой.
Для лендинга и бахнули бы next.js. Про переиспользование функционала можно сделать монорепу с совместными packages
Я в vk тоже работаю, у нас такого нет.
Речь только про наш бизнесс-юнит)
Про переиспользование функционала можно сделать монорепу с совместными packages
Были мысли и про монорепы и про субмодули и даже про пакет в npm.. выбрали путь объединения проектов. Тем более, что это вполне было логично и с других течек зрения.
В плане NextJS спорить не буду. Мне лично он тоже не нравится ))
Используемый стек популярный, проверенный, изученный вдоль и поперек, надёжный, как швейцарские часы:
Современная фронтенд разработка на популярных стеках сегодня выглядит так:
- А давайте придумаем костыль и начнем всем миром решать, как же его использовать в продакшене? Изобрели реакт.
- Не получается, надо придумать еще один костыль, чтобы точно решить все проблем. Придумали стейты, контексты, редаксы, саги и прочую дичь
- Опять не получается, без SSR проекты никому не нужны. Надо изобрести серверный рендеринг, нексты, и прочие ремиксы
- Да чтож такое, всю эту дичь невозможно поддерживать с первого дня! Надо теперь весь этот зоопарк запаковать в правильную архитектуру, вот вам FSD
- Бл...
Москва не сразу строилась))) да и тоже самое можно сказать и про любую другую технологичную область:
- Давайте изобретем двигатель. Изобрели ДВС.
- Блин, он греется сильно. Давайте добавим радиатор охлаждения.
- Эх, с балансом беда, его трясёт как девственницу в первую брачную ночь. Давайте добавим балансировочный вал.
- А вы заметили, что распредвалы не дают оптимальные фазы на всех диапазонах оборотов? Давайте придумаем VVT.
- Вы знаете сколько КПД тратится на нагрев? Давайте придумаем системы рекуперации?
Приходит Маск:
- я там очередную гигафабрику начал строить....
- бл...
Но разве это всё было бессмысленно, вы скажите? =)))
Тогда я жду нового фундаментального решения в этом вопросе. Выражаясь вашим языком — Илона Маска, который аккумулирует весь прошлый опыт и страдания и выдаст новый продукт.
Смешно будет, если этот продукт окажется нативным JS, который и так умеет все чем славится Реакт + HTMX для роутинга без перезагрузки страницы (киллерфича Реакта!) и JSX для компонентного подхода
Но жду я уже слишком долго, видимо придется брать все в свои руки))
На предпоследнем и текущем проектах использовали FSD. За мои 14 лет опыта работы ни в одном проекте не ощущал столько проблем от структуры папок проекта, как в случае этих 2-х проектов с FSD. До этого же в моей практике в основном была группировка по функционалу (folder by feature или feature-based).
Плюсы FSD, которые я ощутил в проектах:
единственная подобная методология, для которой легко можно найти описания ее правил.
структура папок схожа в разных проектах.
быстрое вхождения в проект новых разработчиков, если у них уже был опыт с FSD и на страницах мало логики.
Минусы FSD, которые я ощутил в проектах:
нет однозначного ответа, куда класть общую для разных слайсов бизнес логику. Ощущение, что нужен слой для переиспользуемой разными слайсами бизнес-логики и таким должен был быть слой enities.
не понятно, что делать со связанными бизнес-сущностями, т.к. по FSD они должны быть в разных слайсах, но они используются друг в друге. Они могут быть связаны уже на уровне dto типов, используемых для данных с бека. Попытки запретить или обойти костылями связь между связанными сущностями выглядит для меня ошибкой.
хоть документация обширна, на некоторые важные моменты в ней нет ответа. Официальная документация не избавляет от необходимости заведения своей документации под конкретный проект.
у всех разное понимание FSD. Из-за этого в каждом проекте своя вариация FSD.
зачастую сложно понять, в какой слой поместить тот или иной файл.
хоть организация файлов разных страниц и проектов похожа, но это не дает информации о том, как устроен конкретный проект или функционал страницы. Наоборот, из-за большой декомпозиции в страницах с обилием логики сложнее разобраться, т.к. отвлекаешься на поиск и переключение между файлами, размещенными в разных частях проекта.
из-за большой раздробленности сложнее держать функционал в голове. То есть возрастает когнитивная нагрузка.
падает качество code review, т.к. связанный функционал разбросан по разным верхнеуровневым папкам проекта. Из-за этого при просмотре сложно увидеть общую картину.
в случае удаления, переименования сущности в проекте изменения затрагивает не пару верхнеуровневых папок, а 4-5 (app, entities, features, widgets, pages).
большая разрозненность, увеличение когнитивной нагрузки, сложности с определением, куда лучше поместить файлы, необходимость постоянно продумывать структуру папок проекта, необходимость переключаться между большим количеством папок для разработки даже простой страницы - все это приводит к значительному снижению скорости разработки. Из-за этого она плохо подходит для проектов с высоким темпом разработки.
Также добавлю, что на мой взгляд структура папок слоев и сегментов нарушает high cohesion. Вместо этого получаем destructive decoupling (можно найти описание в этой статье https://habr.com/ru/articles/568216/). Связанный код, который должен располагаться рядом, разбросан по разным папкам-слоям и разным сегментам.
Думаю это хорошо заметно в случае размещение файлов одной страницы по разным слоям (entities, features, widgets, pages).
То же относится и к сегментам. Насколько вижу в проектах, связанный код сегментов одного слайса обычно разбросан по разным сегментам и к тому же получается мешанина из классических MV* слоев. Большинство используют общепринятые сегменты, разделяя функционал по типу, а не по связанному назначению. В итоге получаются например свалки typescript типов в одном файле/папке, когда типы для view слоя, типы для стора (слайса в случае redux toolkit) и dto (dal) типы находятся в одной папке или файле. То же самое с утилитами — утилиты, которые предназначены для разных задач, помещают в один сегмент.
В FSD для слоя shared https://feature-sliced.design/ru/docs/reference/layers#shared описано, что не стоит превращать папку утилит в свалку. Но на практике вижу, что папка утилит и сегменты превращаются в свалки не связанной по назначению бизнес логики.
Во первых, спасибо за такой развернутый комментарий! Спасибо, что делитесь опытом!
Возможно это странно, но по моему опыту работы я сталкивался с большинством описанных трудностей на проектах без fsd - неоднозначность, куда разместить общую для сущностей логику, как содержать связные бизнесс-сущности, особенно если у них есть свои самостоятельные разделы. Свалка в lib, когнитивная нагрузка и тд.
Поэтому я склонен считать, что эти беды не от fsd, а от непонимания его.
Особенно, если говорить про связные бизнесс-сущности. Многие почему-то считают, что сущность - это класс. Я в корне не согласен. Если у вас есть механизм геолокаций, то там будет с дюжину классов - страна, город, индекс, улица, мкрн, дом, подъезд, этаж, квартира. Вы ж не станете это делить на 10 сущностей и потом пытаться объединить через надуманные механизмы?.. это бойлерплейт чистой воды.. Нет, сделайте одну сущность geolocation и радуйтесь. И то если это доменная сущность. А коли нет, то место ей в shared)))
Если у вас проект прям сильно крутится вокруг одной большой сущности, Которая связана сразу со всем в системе (а я встречал такие проекты) ну тогда может быть fsd тут не уместен. Это ж не панацея всё таки.
По части destructive decoupling - опять некорректное прочтение методологии. Я общался в чате на эту тему и мне сторожилы fsd предупредили, что не надо дробить, ради дробления. Всё должно быть компактно по возможности.
Большинство используют общепринятые сегменты, разделяя функционал по типу, а не по связанному назначению.
Это тоже не проблема fsd, а его прочтения. Человек приходит со своими тараканами в голове и пытается делать что-то новое по-старому и прогресса не получается. У меня то же самое произошло в процессе рефакторинга, слава богу мозги вправили и я быстренько всё переделал.
зачастую сложно понять, в какой слой поместить тот или иной файл.
Забавно, но у меня эта проблема возникала всегда на предыдущих проектах, но не в fsd. В fsd я как-то разобрался за пару дней и всё наоборот стало предельно ясно. В моём случае fsd наоборот помог решить данную дилемму.
Возможно это странно, но по моему опыту работы я сталкивался с большинством описанных трудностей на проектах без fsd
Потому что не умеете? Неужели интуитивно понятная структура вызывает трудности? Ну это же откровенное вранье, ни за что не поверю что вы не понимаете для что такое папка layouts, pages, hooks, components, globalState и т.п. Всё что касается страницы лежит в папке со страницей, все что касается конкретного компонента, лежит в папке с компонентом, глобальный стейт соответственно в папке с глобальными состояния и т.д. и т.п. всё максимально интуитивно, логично и просто. Захотел перенести компонент из проекта в проект? Просто одну папку с компонентом скопировал и вуаля.
Поэтому я склонен считать, что эти беды не от fsd, а от непонимания его.
Да нет, как раз таки все эти беды от fsd.
Если у вас проект прям сильно крутится вокруг одной большой сущности, Которая связана сразу со всем в системе (а я встречал такие проекты) ну тогда может быть fsd тут не уместен. Это ж не панацея всё таки.
Открою секрет, большинство проектов имеют много перекрестных связей и разными сущностями между собой. Так что вы правы fsd не подходит почти ни для какого проекта, да чего уже там, по сравнению с традиционный структурой вообще в принципе ни для какого не подходит, разве что вам просто по кайфу тратить каждый день лишнее время на ненужные вещи.
Я общался в чате на эту тему и мне сторожилы fsd предупредили, что не надо дробить, ради дробления. Всё должно быть компактно по возможности.
Только это не работает на практике, вы и все кто использует fsd именно дробите ради дробления, потому что если так не делать, то получится традиционная структура, но вы же хотите выделится, поэтому приходится извращаться.
зачастую сложно понять, в какой слой поместить тот или иной файл.
Забавно, но у меня эта проблема возникала всегда на предыдущих проектах, но не в fsd. В fsd я как-то разобрался за пару дней и всё наоборот стало предельно ясно. В моём случае fsd наоборот помог решить данную дилемму.
Серьезно?
Хм, куда бы положить страницу, в папку pages или в папку assets...
Хм, куда бы положить компонент который используется более 1 раза в разных местах, в папку components или в папку hooks...
Хм, куда бы положить глобальное состояние. в папку globalState или в папку compontns...
Хм, куда бы положить helper функцию в папку helpers или в папку pages...
Ну вы понимаете да насколько это нелепо? Говорить про то, что вы не понимаете что где лежит и должно лежать, а вот FSD вам открыл глаза, хахаха ну это просто реально очень смешно, на серьезных щах такое задвигать это конечно прикол.
Многие почему-то считают, что сущность - это класс.
В 2-х моих проектах сущностью было то, для чего выделен url по rest с набором методов. Для отображения каждой такой сущности были свои страницы. Часть сущностей были вложенными в другие.
Я общался в чате на эту тему и мне сторожилы fsd предупредили, что не надо дробить, ради дробления. Всё должно быть компактно по возможности.
Когда я спрашивал в чате, мне наоборот порекомендовали сразу дробить, чтобы потом не рефакторить, с чем я был не согласен)
Не могли бы вы скинуть ссылку на эту дискуссию? Будет аргументом для объединения лишних слоев.
"Большинство используют общепринятые сегменты, разделяя функционал по типу, а не по связанному назначению."
Это тоже не проблема fsd, а его прочтения. Человек приходит со своими тараканами в голове и пытается делать что-то новое по-старому и прогресса не получается.
Что тут имеете ввиду? Что разработчики не правильно делят на сегменты или что я пытаюсь делать по-привычному? У нас плюс-минус стандартные сегменты и большая их часть написана коллегами, да и я сначала попробовал по-новому и пока продолжаю. Чем больше работаю с сегментами, тем больше ощущаю, что по-старому было лучше. В вашем примере я тоже вижу стандартные папки-сегменты, имена которых мне не говорят, что за функционал внутри них и с каким функционал соседних сегментов он связаны. Если слайс станет большим и в нем будет не 1-2 файла в каждом сегменте, а по 5-10, то сомневаюсь, что будет так же легко разобраться, что с чем связано.
Поэтому я склонен считать, что эти беды не от fsd, а от непонимания его.
Учитывая, что даже у сеньоров (причем у большинства) разное понимание fsd и непонимание каких-то его моментов, то тут беда в том, что или он сложноват для понимания, или документация не достаточно полная и не достаточно понятно его описывает.
Расскажите как легла концепция DRY в FSD архитектуру? Вы отдельно описывайте типы для каждого компонента или переиспользуйте типы? Если второе - какие у вас были сложности и как вы решили проблемы?
Вы про тип Props? В подавляющем большинстве случаев типы у каждого компонента свои.
Есть несколько случаев, компонентов-модификаторов, которые переиспользуют тип от основного блока (это если говорить терминами БЭМ) но они все в пределах одного слайса, поэтому проблем с импортами нет.
В остальном у каждого компонента свои типы. Мне кажется это вполне оправдано.
Как мы приготовили Feature-Sliced Design в VK