У нас во всех проектах были pages. Что надо для перехода на FSD - это папки utils, hooks и ui смешатт в кучу и назвать shared. Папку components разбить на entitys, features. И теперь мы радуемся, что базово у нас 5 папок, зато в каждой папке лежит огромная смесь разных логических деталей
Крутил-вертел месяца 2, но так и не удалось внедрить на крупный реальный проект. Сложилось стойкое впечатление что авторы методологии выходцы из маркетплейсов и социальный сетей. Ибо все звезды сходятся когда у тебя есть куча пересечений простых сущностей и фич типа "заказ", "товар", "написание поста", "лента пользователей" и все очень плохо если это дашборда, криптобиржа или графический редактор файлов. После того как вернулся к помеси модульной структуры с DDD будто сел на ламбу после самопального драндулета.
Каким образом FSD не ложится на дашборду, редактор и дилдобиржу? Складывается впечатление что кто-то с малым кол-вом опыта разработки набрался умных слов и бросается ими в не уместных местах
разумеется, архитектура подбирается под задачу и предметную область. Потому их так много и вот как раз меня поражает что FSD продвигают как лучшую. С фига ли она лучшая? Она под свои задачи. Я так понимаю скоро появится гора проектов которые будут применять FSD и старательно лепить из лошади жирафа. Потому что жираф лучше лошади. Ну и что что заказчик хотел лошадь?! Жираф лучше!
@@user-wv9ds4ft6d автор доклада упомянул, чтоб fsd архитектура подходит больше для продуктовых разработок, т.е которые нужно в долгую поддерживать. Никаких гор проектов не появится, fsd будет только у компаний, которые могут позволить это себе, от миддлов+ команды
Спасибо за доклад, очень интересно. Надо посмотреть более детально. Вообще при разработке в ddd паттернах не наблюдаю зачастую ни одной сущности на фронте, одни объекты значения, как объекты значений на fsd перекладываются
От того, что это идет вниз по иерархии, погода сильно не меняется, только теперь еще необходимо дополнительно создавать пачку бойлерплейтовых папок и файлов для каждой новой сущности вместо того, чтобы делать это 1 раз и навигировать по проекту. Такой подход создает иллюзию атомарности, но время добавления новых фичей только увеличится. Доклад начинается с того, что архитектура должна быть простой и понятной, чтобы тимлиду не приходилось объяснять, как с ней работать, но по итогу лектор ~30 минут объясняет, как с ней работать :/
@@user-bu6fc2bn1e сам пока пытаюсь вникнуть в fsd. По поводу 30 минут объяснения: стоит рассматривать аналогию с фреймворками. Они созданы, чтобы каждый раз люди не изобретали велосипед. Один раз изучил - и нормально. То же самое должно быть с fsd. Правда, я не знаю, насколько хорошо подойдёт это всё для проектов, где нет типичного "пост, коммент" и проч. Да и иногда непонятно, что и куда стоит скидывать.
Что делать если в одной фиче нам нужны данные которые запрашиваются в контексте другой фичи, если нельзя вытягивать отдельные модули (например actions)?
Расскажу как делаю я в подобных случаях. Использую принцип инверсии зависимостей (soliD) Есть 2 разные фичи, где фича X зависит от фичи Y. Например в X нужно получить данные из Y и использовать их (собственно Ваш случай если правильно понял). Реализую фичу Y и отдаю наружу модель. В описанной модели имеется резолвер данных которые нужны в X (но мы не знаем ничего об X, мы просто реализуем контракт). В X я описываю зависимость от абстракции (контракта/интерфейса), а не от конкретной фичи. В итоге, я из фичи Y, передаю в фичу X резолвер и все фичи не знают друг о друге
@@antonmas3451 нет, адаптер в данном случае не нужен. Резолвером я обозначил функцию, которая возвращает данные. Эта функция и передается в другую фичу. p.s. У вас есть слой, где выполняется композиция, например page или widget, там и берете модель одной фичи и передаёте ее другой. Обе фичи должны знать только об абстракции и ничего друг о друге
Самое важное никто из таких докладчиков не разъяснил. Что такое модуль ? И что такое слои в контексте модуля ? В общем доклад простой копирайт. Нет осмысления и нормального объяснения.
@@user-ix2hl4hl2t теперь похоже что да. FSD развивается, документация обновляется. Вероятно то же касается и озвученной в видео позиции относительно обязательности Widgets и Features.
та надо просто депенденси инжекшн с композишн рутом над всей приложкой, да и все. что ети слайсы всякие )) они не вывезут! покуда будут эти "import import", даже если будет все ссылаться в корень модуля - все это кончится спагетти
Ничего не понимаю... это точно архитектура?) По-моему это просто договорённость что и куда класть. Каким образом в папке с кнопками оказывается папка с абстракциями для запросов к апи? Вы всего лишь абстрактно объясняете, а уже выглядит как жесть. Если Entity это сущность, а feature это дейтсвие, то выходит у нас в одной папке лежит сущность ,а вдругой её методы? Или методы там же где и сущность? Тогда возвращаемся к вопросу: а в чем разница между features и entities? И какое направление зависимостей? Сущность (с данными) не может устанавливать зависимость от методов? Или методы не могут подключать к себе данные? И главное: никого не смущает, что при попытке интеграции первая проблема: циклические зависимости! Вы серьезно? Это вообще нетипичная проблема при построении архитектуры! Все проблемы с которыми столкнулся автор доклада прям кричат ,что архитектура выбрана неправильно, но он старался и старательно натягивал. Обозначенные плюсы свойственны любой правильно подобранной архитектуре. Любой. А вот этих минусов я не слышала ни в одной архитектуре... сложно... да это неоднозначно!! а значит в команде будет два человека и один будет орать: это фича, другой - это сущность! И весь рабочй процесс будет напоминать психиатрическую лечебницу, где кто первый надел халат тот и доктор
![[Live] : ONE FIGHT NIGHT 24 วันนี้!! “จาร์เร็ด vs กุสตาโว”](http://i.ytimg.com/vi/ENNA-fsT67c/mqdefault.jpg)
Спасибо за доклад! Интересно было послушать )
вау, спасибо за простое объяснение . Читаю оф документацию, ничего не понятно, а тут вы так просто все по полкам разложили
Спасибо!
Интересно!
Ух классный доклад
Классный доклад, доступно и по делу, спасибо!
У нас во всех проектах были pages. Что надо для перехода на FSD - это папки utils, hooks и ui смешатт в кучу и назвать shared. Папку components разбить на entitys, features. И теперь мы радуемся, что базово у нас 5 папок, зато в каждой папке лежит огромная смесь разных логических деталей
Крутил-вертел месяца 2, но так и не удалось внедрить на крупный реальный проект. Сложилось стойкое впечатление что авторы методологии выходцы из маркетплейсов и социальный сетей. Ибо все звезды сходятся когда у тебя есть куча пересечений простых сущностей и фич типа "заказ", "товар", "написание поста", "лента пользователей" и все очень плохо если это дашборда, криптобиржа или графический редактор файлов. После того как вернулся к помеси модульной структуры с DDD будто сел на ламбу после самопального драндулета.
Каким образом FSD не ложится на дашборду, редактор и дилдобиржу? Складывается впечатление что кто-то с малым кол-вом опыта разработки набрался умных слов и бросается ими в не уместных местах
разумеется, архитектура подбирается под задачу и предметную область. Потому их так много и вот как раз меня поражает что FSD продвигают как лучшую. С фига ли она лучшая? Она под свои задачи. Я так понимаю скоро появится гора проектов которые будут применять FSD и старательно лепить из лошади жирафа. Потому что жираф лучше лошади. Ну и что что заказчик хотел лошадь?! Жираф лучше!
@@user-wv9ds4ft6dУдачи тебе с твоими модульными и всякими атомик дезайнами делать крупный проект
@@user-wv9ds4ft6d автор доклада упомянул, чтоб fsd архитектура подходит больше для продуктовых разработок, т.е которые нужно в долгую поддерживать. Никаких гор проектов не появится, fsd будет только у компаний, которые могут позволить это себе, от миддлов+ команды
Спасибо за доклад, очень интересно. Надо посмотреть более детально. Вообще при разработке в ddd паттернах не наблюдаю зачастую ни одной сущности на фронте, одни объекты значения, как объекты значений на fsd перекладываются
Красава мужик
И получается как раз та штука, которую автор описывал: лезешь что-то поправить в виджете, оттуда в features, оттуда в entities, оттуда в shared
Заметь, вниз по иерархии. А не в types под-компонента biba который подкомпонент boba и так далее
Наоборот, фичи и сущности не должны зависеть от изменений в виджетах.
От того, что это идет вниз по иерархии, погода сильно не меняется, только теперь еще необходимо дополнительно создавать пачку бойлерплейтовых папок и файлов для каждой новой сущности вместо того, чтобы делать это 1 раз и навигировать по проекту. Такой подход создает иллюзию атомарности, но время добавления новых фичей только увеличится. Доклад начинается с того, что архитектура должна быть простой и понятной, чтобы тимлиду не приходилось объяснять, как с ней работать, но по итогу лектор ~30 минут объясняет, как с ней работать :/
@@user-bu6fc2bn1e сам пока пытаюсь вникнуть в fsd. По поводу 30 минут объяснения: стоит рассматривать аналогию с фреймворками.
Они созданы, чтобы каждый раз люди не изобретали велосипед. Один раз изучил - и нормально. То же самое должно быть с fsd.
Правда, я не знаю, насколько хорошо подойдёт это всё для проектов, где нет типичного "пост, коммент" и проч. Да и иногда непонятно, что и куда стоит скидывать.
@@user-bu6fc2bn1eдавай пример архитектуры которая легко масштабируется, не требует анбординга и укладывается в доклад меньше 30мин
Ни чего не понятно, но очень интересно. В entities пишется логика redux и вся бизнес логика, а если нет redux?. От кол-ва папок уже кукуха едет
хахаха орнул с 1:15 ))))
Что делать если в одной фиче нам нужны данные которые запрашиваются в контексте другой фичи, если нельзя вытягивать отдельные модули (например actions)?
Расскажу как делаю я в подобных случаях. Использую принцип инверсии зависимостей (soliD)
Есть 2 разные фичи, где фича X зависит от фичи Y. Например в X нужно получить данные из Y и использовать их (собственно Ваш случай если правильно понял).
Реализую фичу Y и отдаю наружу модель. В описанной модели имеется резолвер данных которые нужны в X (но мы не знаем ничего об X, мы просто реализуем контракт). В X я описываю зависимость от абстракции (контракта/интерфейса), а не от конкретной фичи. В итоге, я из фичи Y, передаю в фичу X резолвер и все фичи не знают друг о друге
@@enslit резолвер это типа адаптер, я вас правильно понял?
@@antonmas3451 нет, адаптер в данном случае не нужен. Резолвером я обозначил функцию, которая возвращает данные. Эта функция и передается в другую фичу.
p.s. У вас есть слой, где выполняется композиция, например page или widget, там и берете модель одной фичи и передаёте ее другой. Обе фичи должны знать только об абстракции и ничего друг о друге
Самое важное никто из таких докладчиков не разъяснил. Что такое модуль ? И что такое слои в контексте модуля ? В общем доклад простой копирайт. Нет осмысления и нормального объяснения.
Это все конечно здорово, но вот слой Widgets обязательный, а слой Features - нет
мне кажется они оба обязательны
@@user-ix2hl4hl2t теперь похоже что да. FSD развивается, документация обновляется. Вероятно то же касается и озвученной в видео позиции относительно обязательности Widgets и Features.
А сайт нормально выводит? выиграл тут пару скинчиков, вот думаю ставить на вывод или поиграть еще)
та надо просто депенденси инжекшн с композишн рутом над всей приложкой, да и все. что ети слайсы всякие )) они не вывезут! покуда будут эти "import import", даже если будет все ссылаться в корень модуля - все это кончится спагетти
Ничего не понимаю... это точно архитектура?) По-моему это просто договорённость что и куда класть. Каким образом в папке с кнопками оказывается папка с абстракциями для запросов к апи? Вы всего лишь абстрактно объясняете, а уже выглядит как жесть. Если Entity это сущность, а feature это дейтсвие, то выходит у нас в одной папке лежит сущность ,а вдругой её методы? Или методы там же где и сущность? Тогда возвращаемся к вопросу: а в чем разница между features и entities? И какое направление зависимостей? Сущность (с данными) не может устанавливать зависимость от методов? Или методы не могут подключать к себе данные? И главное: никого не смущает, что при попытке интеграции первая проблема: циклические зависимости! Вы серьезно? Это вообще нетипичная проблема при построении архитектуры! Все проблемы с которыми столкнулся автор доклада прям кричат ,что архитектура выбрана неправильно, но он старался и старательно натягивал. Обозначенные плюсы свойственны любой правильно подобранной архитектуре. Любой. А вот этих минусов я не слышала ни в одной архитектуре... сложно... да это неоднозначно!! а значит в команде будет два человека и один будет орать: это фича, другой - это сущность! И весь рабочй процесс будет напоминать психиатрическую лечебницу, где кто первый надел халат тот и доктор