Архитектурная методология Feature Sliced / Даниил Крохмаль

Презентация: disk.yandex.ru...

[@DubinArtur]

У нас во всех проектах были pages. Что надо для перехода на FSD - это папки utils, hooks и ui смешатт в кучу и назвать shared. Папку components разбить на entitys, features. И теперь мы радуемся, что базово у нас 5 папок, зато в каждой папке лежит огромная смесь разных логических деталей

[@Afterl1ght]

Крутил-вертел месяца 2, но так и не удалось внедрить на крупный реальный проект. Сложилось стойкое впечатление что авторы методологии выходцы из маркетплейсов и социальный сетей. Ибо все звезды сходятся когда у тебя есть куча пересечений простых сущностей и фич типа "заказ", "товар", "написание поста", "лента пользователей" и все очень плохо если это дашборда, криптобиржа или графический редактор файлов. После того как вернулся к помеси модульной структуры с DDD будто сел на ламбу после самопального драндулета.

[@669pain]

Каким образом FSD не ложится на дашборду, редактор и дилдобиржу? Складывается впечатление что кто-то с малым кол-вом опыта разработки набрался умных слов и бросается ими в не уместных местах

[@ЕкатеринаЗданевич-ы2х]

разумеется, архитектура подбирается под задачу и предметную область. Потому их так много и вот как раз меня поражает что FSD продвигают как лучшую. С фига ли она лучшая? Она под свои задачи. Я так понимаю скоро появится гора проектов которые будут применять FSD и старательно лепить из лошади жирафа. Потому что жираф лучше лошади. Ну и что что заказчик хотел лошадь?! Жираф лучше!

[@rimi4014]

​@@ЕкатеринаЗданевич-ы2хУдачи тебе с твоими модульными и всякими атомик дезайнами делать крупный проект

[@Сергей-о9м6ш]

@@ЕкатеринаЗданевич-ы2х автор доклада упомянул, чтоб fsd архитектура подходит больше для продуктовых разработок, т.е которые нужно в долгую поддерживать. Никаких гор проектов не появится, fsd будет только у компаний, которые могут позволить это себе, от миддлов+ команды

[@YellowPanamka]

Ух классный доклад

[@ГригорийТомилин-ь5я]

Спасибо! Интересно!

[@DzhigurdaAnton]

Спасибо за доклад, очень интересно. Надо посмотреть более детально. Вообще при разработке в ddd паттернах не наблюдаю зачастую ни одной сущности на фронте, одни объекты значения, как объекты значений на fsd перекладываются

[@alexandrchioroglo5612]

Красава мужик

[@DenisB-d5f]

И получается как раз та штука, которую автор описывал: лезешь что-то поправить в виджете, оттуда в features, оттуда в entities, оттуда в shared

[@djon8810]

Заметь, вниз по иерархии. А не в types под-компонента biba который подкомпонент boba и так далее

[@adamburke4496]

Наоборот, фичи и сущности не должны зависеть от изменений в виджетах.

[@MaxHuretski]

От того, что это идет вниз по иерархии, погода сильно не меняется, только теперь еще необходимо дополнительно создавать пачку бойлерплейтовых папок и файлов для каждой новой сущности вместо того, чтобы делать это 1 раз и навигировать по проекту. Такой подход создает иллюзию атомарности, но время добавления новых фичей только увеличится. Доклад начинается с того, что архитектура должна быть простой и понятной, чтобы тимлиду не приходилось объяснять, как с ней работать, но по итогу лектор ~30 минут объясняет, как с ней работать :/

[@aquinary.]

@@MaxHuretski сам пока пытаюсь вникнуть в fsd. По поводу 30 минут объяснения: стоит рассматривать аналогию с фреймворками. Они созданы, чтобы каждый раз люди не изобретали велосипед. Один раз изучил - и нормально. То же самое должно быть с fsd. Правда, я не знаю, насколько хорошо подойдёт это всё для проектов, где нет типичного "пост, коммент" и проч. Да и иногда непонятно, что и куда стоит скидывать.

[@669pain]

​@@MaxHuretskiдавай пример архитектуры которая легко масштабируется, не требует анбординга и укладывается в доклад меньше 30мин

[@konstantinalekseev5789]

Самое важное никто из таких докладчиков не разъяснил. Что такое модуль ? И что такое слои в контексте модуля ? В общем доклад простой копирайт. Нет осмысления и нормального объяснения.

[@singlebw4065]

Ни чего не понятно, но очень интересно. В entities пишется логика redux и вся бизнес логика, а если нет redux?. От кол-ва папок уже кукуха едет

[@chups09]

Что делать если в одной фиче нам нужны данные которые запрашиваются в контексте другой фичи, если нельзя вытягивать отдельные модули (например actions)?

[@enslit]

Расскажу как делаю я в подобных случаях. Использую принцип инверсии зависимостей (soliD) Есть 2 разные фичи, где фича X зависит от фичи Y. Например в X нужно получить данные из Y и использовать их (собственно Ваш случай если правильно понял). Реализую фичу Y и отдаю наружу модель. В описанной модели имеется резолвер данных которые нужны в X (но мы не знаем ничего об X, мы просто реализуем контракт). В X я описываю зависимость от абстракции (контракта/интерфейса), а не от конкретной фичи. В итоге, я из фичи Y, передаю в фичу X резолвер и все фичи не знают друг о друге

[@antonmas3451]

@@enslit резолвер это типа адаптер, я вас правильно понял?

[@enslit]

@@antonmas3451 нет, адаптер в данном случае не нужен. Резолвером я обозначил функцию, которая возвращает данные. Эта функция и передается в другую фичу. p.s. У вас есть слой, где выполняется композиция, например page или widget, там и берете модель одной фичи и передаёте ее другой. Обе фичи должны знать только об абстракции и ничего друг о друге

[@fizzbuzz5807]

Это все конечно здорово, но вот слой Widgets обязательный, а слой Features - нет

[@АрманРахимов-ж8г]

мне кажется они оба обязательны

[@fizzbuzz5807]

@@АрманРахимов-ж8г теперь похоже что да. FSD развивается, документация обновляется. Вероятно то же касается и озвученной в видео позиции относительно обязательности Widgets и Features.

[@ЕкатеринаЗданевич-ы2х]

Ничего не понимаю... это точно архитектура?) По-моему это просто договорённость что и куда класть. Каким образом в папке с кнопками оказывается папка с абстракциями для запросов к апи? Вы всего лишь абстрактно объясняете, а уже выглядит как жесть. Если Entity это сущность, а feature это дейтсвие, то выходит у нас в одной папке лежит сущность ,а вдругой её методы? Или методы там же где и сущность? Тогда возвращаемся к вопросу: а в чем разница между features и entities? И какое направление зависимостей? Сущность (с данными) не может устанавливать зависимость от методов? Или методы не могут подключать к себе данные? И главное: никого не смущает, что при попытке интеграции первая проблема: циклические зависимости! Вы серьезно? Это вообще нетипичная проблема при построении архитектуры! Все проблемы с которыми столкнулся автор доклада прям кричат ,что архитектура выбрана неправильно, но он старался и старательно натягивал. Обозначенные плюсы свойственны любой правильно подобранной архитектуре. Любой. А вот этих минусов я не слышала ни в одной архитектуре... сложно... да это неоднозначно!! а значит в команде будет два человека и один будет орать: это фича, другой - это сущность! И весь рабочй процесс будет напоминать психиатрическую лечебницу, где кто первый надел халат тот и доктор

[@MarianEleanor]

А сайт нормально выводит? выиграл тут пару скинчиков, вот думаю ставить на вывод или поиграть еще)

[@ahmedrapira7610]

та надо просто депенденси инжекшн с композишн рутом над всей приложкой, да и все. что ети слайсы всякие )) они не вывезут! покуда будут эти "import import", даже если будет все ссылаться в корень модуля - все это кончится спагетти

[@aceracer5556]

Спасибо за доклад! Интересно было послушать )

[@ВладОся-з7ь]

хахаха орнул с 1:15 ))))

[@dollgarden588]

вау, спасибо за простое объяснение . Читаю оф документацию, ничего не понятно, а тут вы так просто все по полкам разложили

[@ingvarr6235]

Классный доклад, доступно и по делу, спасибо!