Эволюция архитектуры. Как мы пришли к FSD / Сергей Пономарёв, Purrweb
HTML-код
- Опубликовано: 28 сен 2024
- «Архитектура фронтенда» - это достаточно молодое понятие, поэтому часто оно трактуется по-разному. От этой трактовки зависит майндсет фронтенд-разработчика на старте разработки приложения. Как работать с функциональными и нефункциональными требованиями, ограничениями системы и приоритизацией?
Об основных понятиях архитектуры и опыте перехода на методологию Feature-Sliced-Design рассказывает Сергей Пономарёв, СТО Purrweb.
Подробнее о докладе и спикере: yatalks.yandex...
Баста хорош
Хороший доклад! Простым, немного резким языком.
Джуны побитые в синяках )
Ахахахахаха
«Чем ниже слой - тем он глупей»
Спорное утверждение конечно, вообще единственный плюс как по мне. Единообразная структура для всех проектов, если у вас много команд - это позволяет накручивать разную инфру достаточно легко, потому что у всех приложений все лежит в одном месте. Ну еще из плюсов - слои зависят друг на друга только в одном направлении.
Самый большой минус - одна функциональность часто размазана по нескольким папкам и это сложно рефакторить
Можно ссылку на презентацию?
Я просмотрел ни один ролик по так называемой FSD архитектуре и в принципе смысл FSD понятен. Но такое чувство, что все эти объясняльщики сами ничего не понимают. Они все повторяют одно и то же друг за другом на рунглише для русскоязычных людей. Объяснять нужно на простом языке, чтобы поняли новички в программировании. В принципе логика разложения по папкам понятна, но возникает вопрос безопасности и защищённости о хака.
о какой безопасности и каком хаке вы говорите?
Это просто методолгия, что в какую папочку сложить, что может модуль импортировать, а что нет, вот и все
Спасибо за доклад. На мой взгляд доклад слабоват для такой конференции. Не раскрыта тема проблем, с которыми вы сталкивались, а они сто процентов были.
По поводу переписывания. У меня есть опыт и это не быстро, особенно если проект не знакомый.
Layout должен лежать в shared. Layout не должен содержать никакой логики в себе. Он должен принимать в пропсах jsx элементы и все. Его базовая задача содержать разметку и стили.
Если размещаете его в виджетах - значит вы импортируете логику/компоненты из слоев ниже. А явные зависимости всегда хуже неявных.
Одинаковых по разметке лэйоутов в widgets, будет кратно больше чем в shared (если просто использовать слоты для компонентов).
Спасибо, что поделились!
Как согласуется каплинг/кохижн с тем, что все фичи лежат в одной папке?
сегменты то разные, к примеру, user, cart, product все собираются в слое widget где также user, cart, product
@@TheTexPro Фичи и виджеты тоже делятся на слайсы (сегменты - это уже ниже уровнем)? Почему бы тогда просто не сделать "модуль" user, и туда сложить всё, что к нему относится: сущность, фичи, виджеты...?
@@SuhushinAS Такой подход тоже возможен, однако со временем понадобится горизонтальный разнос и декомпозиция, потому как в модуле будет дублироваться логика из других моделей на уровне фич или сущностей.
Вариант с 1 модулем и его подслоями повышает зацепление и уменьшает связность. Однако в fsd предлагается подход горизонтального разноса модулей, К примеру, виджет каталога widget/catalog, где слева фильтр как фича в модуле feature/catalog/filter и листинг товаров как feature/catalog/list с пагинацией как feature/catalog/pagination
Если по требованиям нужно добавить , убрать, заменить функционал то мы можем как добавить нужные фичи с новым моделям, так и доработать уже имеющиеся , вместо каталога выставить листинг в виде таблицы catalog/table или заменить фильтр, однако их модули будут как catalog и раскинуты по слоям без жёсткой сцепке
@@TheTexPro Не очень удачный пример: catalog - это не сама сущность, а представление для других сущностей, товаров, пользователей, ...
Его будет правильнее разместить в shared/catalog, а внутри уже filter, list, paginaton, table, ...
В модуле user, можно уже сделать UserCatalog, который будет использовать shared части, их будет так же легко заменить.
И дублирования не будет, т.к. в таком подходе импорты между модулями не запрещены (это правило и в fsd мало, кто соблюдает).
Каплинг/кохижн наоборот будет лучше, потому что всё, что catalog будет в одном месте, а не размазан по разным местам.
@@SuhushinAS вот они минусы fsd, вечные дебаты, куда-что класть и как оно должно взаимодействовать xD
Однако, в shared лежит ui без логики, фильтрация, пагинация, листинг с карточками - это все связь и бизнес ценность + юзер действия. В fsd нельзя просто так положить в слой и забыть про него, функционал и требования меняются и придется либо поднимать на слой выше, либо распределять горизонтально. К примеру, catalog/filter там же фильтрация и связь со стором + состоит из разным частей, ползунок слайдер для цены, разные галочки брендов и тд, потому кладется в features/catalog/filter, однако, если появится новый тип фильтра, скажем по наименованию, он тоже может "уместиться" в features/catalog/filter, а сам элемент - searchFilter уже пойдет в entities/catalog/filter
все прикольно до тех пор пока твой шеред не превратился в огромный пулл папок