Есть такой инструмент Plantuml, это слой архитектуры. Обычно этот слой скрывают от команды. Его создают и потом практически не меняют, держат в секрете. Не мудрено что автор ничего не знает про слой архитектуры системы. Так же есть слой архитектуры бизнеса, Bpmn используют в основном. Это в ещё большей секретности держат. И как правило стараются архитектуру на bpmn выносить за пределы кода, максимум в лоу код. В обще автор молод, бизнес аналитика это удел топов, но это и самая интересная компетенция. Обычно это кто старше 40, а то и 50. С опытом не только фронтенд бэкэнд но и ассемблер порой армовский, чтобы видеть глубоко от общего к частному архитектуру разрабатываемой системы.
"Каждый пост тоже будет являться виджетом" (5:51) - вот тут по моему есть небольшая ошибка. Виджетом тут будет являться весь PostList, который эти посты рендерит. А каждый пост это entity, который пропсом принемает какие либо actions (в нашем случае это лайк и коммент поста, которые пробрасываются ему в момент рендера в PostList). Сам PostCard (entity) абсолютно не знает, что за actions он будет принимать, но эти actions он внутри себя просто отрисовывает, если они есть. То, что кнопка лайка была названа виджетом (6:05), попахивает нарушением правил FSD, потому что в этом случае пост ( ранее тоже названый виджетом ) использует внутри себя другой виджет ( вот эту кнопку лайка ), а разрешено использовать только нижележащие слои. Лично я бы положил эту кнопку лайка в "ui" сегмент фичи, которая также отрисовывает и количество лайков конкретного поста ( во время рендера можно ведь прокинуть id конкретного поста, а дальше уже дело фичи отрисовать количество ). На счет того, что "фото" было помещено в entities тоже у меня возникают какие-то сомнения - фото это просто фото же, а entities - я частенько даю им такое определение - это как бы визуальная репрезентация того, что хранится в базе данных. Ну например PostCard это же entity, который показывает в виде карточки ту информацию, что хранится в бд. Кстати, разве слой processes не вычеркнули? (9:39) Лично я предпочел бы хранить "api" сегмент или запрос к серверу в том же модуле (slice), в котором он используется (например features/like-post/api/ ), просто чтоб все было рядом и не шататься между разными слоями, но это уже не правило FSD. По остальному примечаний у меня вроде нет, а кто хочет еще подробнее про FSD - рекомендую у UlbiTV посмотреть ролик про архитектуры фронта. Потом можно на официальном сайте посмотреть документацию и примеры работ, а дальше... только практика, всем удачи🤞
Привет! Спасибо за такой подробный комментарий. Я прочел, и на самом деле по общему счету ты прав, я ошибся, за что прошу прощения. Не хватило информации об устаревшем слое. Я все это учту и постараюсь впредь быть более внимательным
А можешь рассказать как это помогает программировать? Пока я вижу только чистую субъективщину( кто как понимает так и делает, а каждый понимает так как ему удобно с его угла зрения). Просто хотелось бы на практике увидеть как это помогает вносить новые фичи, переделывать старые.
@@vgsnva Это очень сильно помогает в структурировании проекта, когда у тебя 100500 файлов/папок и так далее. Помогает не запутаться в проекте в будущем и создает понятную структуру
Когда то и я абсолютно идентично относился к отношениям и семье. Это и есть главная ошибка, так как есть отношения, есть семья. Два абсолютно разных измерений. Имея семью: супругу и детей. Нужно и судить исходя из этого факта. Потому что ты уже не холостой парень, ты лично отвечаешь за детей. Это твое решение и решение супруги взять такую огромную ответственность на себя. Соответсвенно, вы должны детям обеспечить: детство, здоровое самолюбие и адекватную самооценку. Разрушая брак, рушиться их психика. Это все априори подразумевает что вы оба с супругой будете делать все для обратного. Это не просто. Думаете о браке? Значит прими следующее: все проблемы можно решить. Рушить брак, это не обсуждаться. Это фундамент, на котором нужно строить. Не готовы? Не делайте детей. Смотря на некоторых родителей, возникает вопрос - почему нету до сих пор что-то вроде обязательных «курсов для будущих родителей» много чего станет лучше, что касается воспитания. Я конечно не думаю, что Эдвард прочтет это, но поскольку считаю эту инфу очень важной, может кому-то поможет.
Вот это прикол…что то у ютуба пошло не так. Я этот комментарии вообще под другим видео оставлял. А это, видео, про реакт было следующее. Жесть. Удалить комментарии? Совсем не в тему. Но спасибо за лайк! 👍🏼
Неплохое видео, спасибо. FSD: добавлю, что начиная работать с fsd не надо упарываться в декомпозицию - достаточно выбрать основной слой(например, pages или features) и писать весь код там, а дальше уже по мере необходимости декомпозировать. Как декомпозировать - это вопрос вкуса - примерно, как сортировать папки на компьютере. Нет единственно верного варианта. По итогу, FSD - это инструмент, который дает качественные, универсальные абстракции, способные эффективно структурировать код в большинстве доменов.
Мы испрльзуем принцип fsd, но подогнали под себя. Добавили слой routers между app и остальными. И сократили другие слои. Так между app и shared мы оставили entities и features(объединяем несколько сущностей), иногда pages для объединения фичей. И после добавили routers. Очень удобно вышло 👍🏻
Не фронт разработчик, но фронтовые задачи иногда делаю, понравилась вариация фиче ориентированной концепции, когда компоненты лежат в рамках фич, и выносятся на уровень иерархии так чтобы использоваться только в дочерних папках, но не в родительских, общие базовые же компоненты типо кнопок, тогглов, тупых иконок и тд используемых в нескольких фичах можно вынести в отдельный проект или папку. Потому что для большого приложения условные папка components заспамилась настолько сильно, что проще что-то найти через поиск по возможному имени файла, чем скроллить компоненты.
Привет. Яндекс сам продвигает эту методологию на своих митапах и других мероприятиях. На сайте FSD есть список компаний, которые ее используют, помимо Яндекса там немало русскоязычных гигантов
Как то вы странно понимаете FSD. Не надо буквально как есть подгонять под свой проект описанные термины. Главная идея - группировать логику по фичам, а не типам. Например вместо общих папок для компонентов или состояния делайте папку фичи, например "каталог" и в ней уже и компонент каталога и состояние каталога . Кроме фич в архитектуре приложения понадобятся дополнительные слои, например для объединения всех фич в единый флоу (app), для стандартизации ui - библиотека ui-kit или просто утилиты - вот они и образует "слои" с названиями какие вам будут понятнее).
FSD очень сильно распиарена и переоценена). В большинстве случаев достаточным будет: 1. Понятное распределение файлов по известным директориям: redux, components - ui-kit, hooks, contexts, api. 2. Умение писать понятный, чистый код. Декомпозировать, выносить логику в хуки.
Привет. То, что ты написал имеет смысл. В большинстве случаев это идеально подойдет. Но есть и правда очень загруженные проекты, работа с которыми вызывает сильную головную боль без правильной организации. Опять таки каждый сам для себя выбирает как и с чем ему работать. Главное, чтобы было удобно)
Если у тебя проект небольшой то фсд создаст больше проблем чем пользы, но как только проект становится более или менее большим и в папке components будет хотя бы 50 компонентов тогда начнутся проблемы, на мой взгляд фишка фсд в уменьшении связанности файлов. У этой методологии есть проблемы с переходом на нее потому что привыкнуть к ее сущностям и легко определять что к чему относится бывает не так просто
Действительно хорошая подача. Вот только бы еще проверка озвученной информации была бы подтверждена реальной практикой автора канала. Пересказ доков и формальный пример минимальной сложности может привести любой))
8:55 - "для тех кто только напичает..... может показаться сложным и непонятным" - я тебе больше скажу, я в разработке много лет и если бы я не знал эти архитектуры я бы ничего не понял из видео, особенно слово "срезы" что это вообще такое )))))
А, понял, ты дословно с английского перевел slice. Не нужно так делать, нужно адаптировать слово ))) Так как в английском могут быть еще другие значения: a part or share of something, especially an amount of money
Обе архитектуры не жизнеспособны на крупных, развивающихся проектах: В первой проблема постоянных скачков между частями приложения, что в случае работы более 5 человек в параллели выльется в трэш с мержами. Во второй запаришься компоненты из папочки в папочку перекидывать. И это с учетом того, что паттерн был разработан для юай библиотек, а не для проектов.
@@atmaliveзависит от ситуации - не бывает идеальной архитектуры, которая все решает. 1. В любом случае накосячите с выбором архитектуры и придется менять/переписывать и т.д. все собственно как и с кодом 2. Имеет смысл всегда думать о базовых вещах: а. Бизнес логика всегда отдельно от презентационной логики (это про вью и контроллеры, фабрики, сервисы - можно назвать как угодно, смысл в том, что если есть возможность разделить ответственность - ее необходимо разделить) б. все связанное с конкретной задачей должно быть в одном месте (есть у вас фича и все по этой фиче должно быть в одной папочке (древе папочек), исключение - переиспользуемая часть, НО с переиспользлванием нужно быть аккуратным, если много условий в одном месте - значит это уже не переиспользуемый функционал, а разный, который почему-то смержили в одном месте - и лучше иметь 10 разных копий, чем одну, но с кучей условий) в. Вся группировка базируется только и только на основе задач, которые решает та или иная часть приложения (не по размеру как атомик, не по группам, как в базовом мвс, а именно по логичным человеческим задачам) В целом все равно любую архитектуру потом исправляют докручивают. Главное знать основы, а дальше думать, что работает для команды, а что нет.
@@VitaliKarepanauу меня как раз родилась такая проблема, как вы описали в 2.б. решил тупо копировать и добавлять в комплекте функционал под каждую страницу, потому что невозможно было поддерживать переиспользуемый компонент с переполненным функционалом в зависимости от условий пропсов. Дизайнер захотел везде один комплект по сути, но с кучей разных функций дополнительных
Хорошая и чёткая подача, хороший ролик. Особенно порадовало качество звука (сорри, я немного профдеформирован в этом вопросе=)) Мне как шарповому бекендеру периодически бывает интересно как там фронты поживают, что и как пишут и тд)
а еще совет))) не облайкивать комментарии. Я столкнулся с баном от ютуба за лайки всех комментов к своим видео, якобы за "спам" и не разбанили же ведь(
Привет. Да, мне уже об этом писали. У них на оффициалтном сайте есть много примеров проектов с их методологией. Но если вдруг будет интересно, то я запишу обзор на один из таких проектов, либо попробуем сделать декомпозицию, только дайте знать)
А разве такие компоненты как форма для добавления поста, поле добавления комментария, а так же кнопка с лайками не уходят в фичи? По идеи они как раз отвечают за действия.
Привет, да. Сами инпуты являются переиспользуемыми компонентами, а уже функционал для добавления поста или написание комментария отнесем в фичи, это действия пользователя. Возможно я неточно донес свою мысль, прошу за это прощения, постараюсь быть внимательнее
Привет! Веб-приложение это по сути лишь программа, которая выполняется на веб-сервере и доступна через браузер. Использование компонентов позволяет создавать интерактивные и динамичные пользовательские интерфейсы. Так что да)
Хорошее видео. но когда распределял куда что соотнести. сказал, что карточка поста это виджет, но по докам это ui элемент entities. так как относиться к сущности поста.
Это с другой стороны не очевидная архитектура, вы в видео post, вынесли в виджеты, кто то выносит его в entities И еще такой вопрос, вы в виджеты вынесли отдельные блоки, но в таком случае, где будет лежать общий для всего приложения layout ? Явно уже не в виджетах, ведь он не может импортировать компоненты с собственного слоя
Привет, большое спасибо!) По поводу архитектуры: в планах записать более подробное видео. Про архитектуру на бэке подсказать не могу, в данной области не специалист к сожалению) И да, FSD можно и с react native интегрировать, не проблема)
Привет. Понятие правильная на самом деле у всех свое. Я рассказал про данные структуры, основываясь на своем коммерческом опыте и опыте других фронтенд разработчиков. Сейчас FSD используют практически все крупнейшие компании. И, вероятно, когда ты придешь в какой либо большой проект, в его стэк будет входить данная методология. + Она одна из самых удобных
Как называется методология и является ли это методологией где следующая архитектура: 1. Components (shared), переиспользуемые (кнопки, инпуты, лэйаут) может функции с хуками ещё 2. Pages - собранные страницы, со своими папками компонентов, которые сделаны под эту страницу. У меня в чем проблема: компоненты вроде одинаковые,но вариация использования большая, то иконка добавляется в дроплист, то он мультипл ,а не соло, то модалка для создания или редактирования объекта, то такая же модалка, но только для просмотра. Пытался сделать с кучей пропсов для переиспользования, но в итоге компоненты так были переполнены функционалом, что решил идти по выше описанной методологии
Привет! В Features твоя задача реализовать механику постановки лайка и через public api экспортировать его и использовать уже далее в проекте. FSD это методология по которой ты будешь структурировать файлы в проекте, а как ты реализуешь дальнейшую работу зависать уже от требований проекта. Если вдруг какие то нюансы вызовут трудности, то в описании есть ссылка на документацию - она очень подробная и на русском языке!)
Привет, спасибо за вопрос. UI-сегмент является уникальным для конкретного среза, то есть содержащаяся в нем логика не должна использовать больше нигде. Если у тебя есть одинаковая кнопка в разных срезах то она по своей сути является переиспользуемым компонентом. В крайних случаях можно дублировать логику, зависит от ситуации, но лучше максимально такого избегать
@nan-simon вытащи кнопку в фитчу, если она содержит бизнес логику. Для ui компонента сущности сделай пропс типа ReactNode. И по месту использования на уровни виджета или страницы сделай композицию сущности с фитчевым пропсом.
@@xlok1e-it, да на примере какого-нибудь мини приложения было б не плохо. В русском сегменте проектов с архитектурой не видел. Будет + огромный. Тот же самый приславутый todolist
Да, каждый всегда для себя что-то найдет) Что касательно удобства - то лично для меня и для многих других фронтенд разработчиков, в том числе из крупных организаций, данная методология очень упростила поддержку проекта в долгосрочной перспективе. А так, я всегда считаю, что надо делать так, как удобно лично тебе, однако забивать на такие факторы, как поддержка и масштабируемость - не лучшая перспектива)
Привет. Разработчики на сайте оставили вот такую статью - feature-sliced.design/ru/docs/guides/tech/with-nextjs. Тут как раз про конфликты FSD + Next и как их избежать
Привет. Бизнес логика распределяется по нескольким слоям. К примеру Features реализует бизнес-логику взаимодействия пользователя с приложением. Но например Pages отвечает только за отображение страницы, а бизнес-логика переносится на нижележащие слои
Думаю есть альтернативный ответ на это вопрос, взял из доки, речь о сегментах: model - модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
5 лет разрабатываю на реакте. Понятие архитектура - довольно абстрактное. То что здесь рассказано - это организация директорий и файлов. Причем организация довольно запутанная и неочевидная. Никогда не буду ее применять и уж тем более советовать кому либо
Привет! Ты прав, в маленьком проекте может принести больше вреда, нежели пользы. С другой стороны, если в будущем на проект есть планы, то методологию можно внедрять постепенно, а не сразу)
Привет. Спасибо, что поинтересовался. С недавних пор нигде не работаю. С головой ушел в контент: ютуб, телеграмм. Времени на это уходит не мало, поскольку хочу сделать качественно)
Предлагаю такой подход: 1) applications. Тут все понятно, если у вас есть допустим форум и магазин, глупо их делать в одной app, хотя и в разных проектах тоже не всегда хорошо, ведь могут существовать множественные связи. 2)Название может быть разным, допустим Features. Отвечает за конкретный функционал: товары, заказы, корзина. 3.1)модели: понятно 3.2)data-access: сервисы, которые загружают наши модели из сервера 3.3)pages: понятно, конкретнве страниця, 3.4)components(widgets): тоже понятно. 3.5)ui (только представления, без подгрузки с сервера) 3.6) разные другие сервиса (гуарды, интерсепторы...), Могут быть перенесены на слои повыше. В общем, между этим и показанной структурой очень много схожего
Мне кажется образовательные каналы надо помечать какой то меткой , которую нужно заслужить... А то очень много субъективного мнения, а плохих роликов ещё больше
Привет. Понимание чего-либо всегда приходит на практике) Если ты сейчас чего-то не понимаешь, то не стоит убиваться и пытаться насильно забить себе голову. Пробуй, создавай и спустя время все встанет на свои места!
![Егор Локи [Frontend]](http://yt3.ggpht.com/p6jQt6B3waPn5BkBQaFytk2ZFzx4bIagiE058qmpuBUWiIeKWGfqpTNRAes1fBKEGGuxFsbls38=s48-c-k-c0x00ffffff-no-rj)
💥Полезный контент про разработку + памятка FSD - t.me/xlok1e/21
UPD: Слой Processes устарел и больше не используется
Есть такой инструмент Plantuml, это слой архитектуры. Обычно этот слой скрывают от команды. Его создают и потом практически не меняют, держат в секрете. Не мудрено что автор ничего не знает про слой архитектуры системы. Так же есть слой архитектуры бизнеса, Bpmn используют в основном. Это в ещё большей секретности держат. И как правило стараются архитектуру на bpmn выносить за пределы кода, максимум в лоу код. В обще автор молод, бизнес аналитика это удел топов, но это и самая интересная компетенция. Обычно это кто старше 40, а то и 50. С опытом не только фронтенд бэкэнд но и ассемблер порой армовский, чтобы видеть глубоко от общего к частному архитектуру разрабатываемой системы.
"Каждый пост тоже будет являться виджетом" (5:51) - вот тут по моему есть небольшая ошибка.
Виджетом тут будет являться весь PostList, который эти посты рендерит.
А каждый пост это entity, который пропсом принемает какие либо actions (в нашем случае это лайк и коммент поста, которые пробрасываются ему в момент рендера в PostList). Сам PostCard (entity) абсолютно не знает, что за actions он будет принимать, но эти actions он внутри себя просто отрисовывает, если они есть.
То, что кнопка лайка была названа виджетом (6:05), попахивает нарушением правил FSD, потому что в этом случае пост ( ранее тоже названый виджетом ) использует внутри себя другой виджет ( вот эту кнопку лайка ), а разрешено использовать только нижележащие слои. Лично я бы положил эту кнопку лайка в "ui" сегмент фичи, которая также отрисовывает и количество лайков конкретного поста ( во время рендера можно ведь прокинуть id конкретного поста, а дальше уже дело фичи отрисовать количество ).
На счет того, что "фото" было помещено в entities тоже у меня возникают какие-то сомнения - фото это просто фото же, а entities - я частенько даю им такое определение - это как бы визуальная репрезентация того, что хранится в базе данных. Ну например PostCard это же entity, который показывает в виде карточки ту информацию, что хранится в бд.
Кстати, разве слой processes не вычеркнули?
(9:39) Лично я предпочел бы хранить "api" сегмент или запрос к серверу в том же модуле (slice), в котором он используется (например features/like-post/api/ ), просто чтоб все было рядом и не шататься между разными слоями, но это уже не правило FSD.
По остальному примечаний у меня вроде нет, а кто хочет еще подробнее про FSD - рекомендую у UlbiTV посмотреть ролик про архитектуры фронта. Потом можно на официальном сайте посмотреть документацию и примеры работ, а дальше... только практика, всем удачи🤞
Когда-нибудь люди поймут в 2024, что реакт не актуален про сравнению с его конкурентами.(P.S. Ангулару он даже в подметки не годится)
Привет! Спасибо за такой подробный комментарий. Я прочел, и на самом деле по общему счету ты прав, я ошибся, за что прошу прощения. Не хватило информации об устаревшем слое. Я все это учту и постараюсь впредь быть более внимательным
@@easystyle3378 поставлю за тебя свечку в церкве пожалуй
А можешь рассказать как это помогает программировать? Пока я вижу только чистую субъективщину( кто как понимает так и делает, а каждый понимает так как ему удобно с его угла зрения). Просто хотелось бы на практике увидеть как это помогает вносить новые фичи, переделывать старые.
@@vgsnva Это очень сильно помогает в структурировании проекта, когда у тебя 100500 файлов/папок и так далее. Помогает не запутаться в проекте в будущем и создает понятную структуру
Когда то и я абсолютно идентично относился к отношениям и семье. Это и есть главная ошибка, так как есть отношения, есть семья. Два абсолютно разных измерений. Имея семью: супругу и детей. Нужно и судить исходя из этого факта. Потому что ты уже не холостой парень, ты лично отвечаешь за детей. Это твое решение и решение супруги взять такую огромную ответственность на себя. Соответсвенно, вы должны детям обеспечить: детство, здоровое самолюбие и адекватную самооценку. Разрушая брак, рушиться их психика.
Это все априори подразумевает что вы оба с супругой будете делать все для обратного. Это не просто.
Думаете о браке? Значит прими следующее: все проблемы можно решить. Рушить брак, это не обсуждаться. Это фундамент, на котором нужно строить.
Не готовы? Не делайте детей.
Смотря на некоторых родителей, возникает вопрос - почему нету до сих пор что-то вроде обязательных «курсов для будущих родителей» много чего станет лучше, что касается воспитания.
Я конечно не думаю, что Эдвард прочтет это, но поскольку считаю эту инфу очень важной, может кому-то поможет.
Вот это прикол…что то у ютуба пошло не так. Я этот комментарии вообще под другим видео оставлял. А это, видео, про реакт было следующее. Жесть. Удалить комментарии? Совсем не в тему. Но спасибо за лайк! 👍🏼
@@Sergfio_S.F читал до конца внимательно пытаясь понять суть того что написано и как оно связано с темой
Мне уже показалось, тут какая-то сложная аналогия, начал представлять, что дети - это срезы слоёв-родителей и т.д. 😅
Хах, а я думал, что нужны курсы как построить правильную иерархию в семье 😅
Неплохое видео, спасибо.
FSD: добавлю, что начиная работать с fsd не надо упарываться в декомпозицию - достаточно выбрать основной слой(например, pages или features) и писать весь код там, а дальше уже по мере необходимости декомпозировать.
Как декомпозировать - это вопрос вкуса - примерно, как сортировать папки на компьютере. Нет единственно верного варианта.
По итогу, FSD - это инструмент, который дает качественные, универсальные абстракции, способные эффективно структурировать код в большинстве доменов.
Привет. Спасибо за комментарий, ты написал все верно)
Спасибо большое, Егор! Очень доступно о сложном
Привет. Тебе спасибо за просмотр! Рад помочь!)
КАК же долго я ждал таких видео!! жду еще твоих роликов!
Привет! Очень теплые слова, спасибо) Вскоре выпущу еще много полезного, забегай)
Мы испрльзуем принцип fsd, но подогнали под себя. Добавили слой routers между app и остальными. И сократили другие слои. Так между app и shared мы оставили entities и features(объединяем несколько сущностей), иногда pages для объединения фичей. И после добавили routers. Очень удобно вышло 👍🏻
Проблемы есть только с типом для AppState от стора редакса. Мы хитрые и сделали реэкспорт из shared 😮
Привет! Интересно получилось, спасибо, что поделились)
Отличный контент и подход к подаче материала, приятно слышать и видеть) Очень просто о сложном, так держать)
Спасибо за поддержку, рад стараться!)
Не фронт разработчик, но фронтовые задачи иногда делаю, понравилась вариация фиче ориентированной концепции, когда компоненты лежат в рамках фич, и выносятся на уровень иерархии так чтобы использоваться только в дочерних папках, но не в родительских, общие базовые же компоненты типо кнопок, тогглов, тупых иконок и тд используемых в нескольких фичах можно вынести в отдельный проект или папку. Потому что для большого приложения условные папка components заспамилась настолько сильно, что проще что-то найти через поиск по возможному имени файла, чем скроллить компоненты.
Привет! Да, очень тяжело работать, когда все скинуто в одну папку. Наступает хаос и масштабировать проект становится сложно)
"Этой технологией пользуются программисты из Яндекса". Не Яндекс в своих проектах использует, в просто программисты где-то используют
Привет. Яндекс сам продвигает эту методологию на своих митапах и других мероприятиях. На сайте FSD есть список компаний, которые ее используют, помимо Яндекса там немало русскоязычных гигантов
@@xlok1e-itне Яндекс, а некоторые из сотен команд.
слой процессов deprecated же? вроде как писали что он особо не нужен и отменили
Привет. Это так, он уже не используется. Забыл об этом упомянуть
кем отменён? где-то есть консорциум и стандарт?
Не понял твой вопрос немного
@@singularity3901вово. В отличие от бека, на фронте каждый как хочет пишет.
Очень приятно слушать, все просто и понятно!
Привет! Большое спасибо!
Как то вы странно понимаете FSD. Не надо буквально как есть подгонять под свой проект описанные термины. Главная идея - группировать логику по фичам, а не типам. Например вместо общих папок для компонентов или состояния делайте папку фичи, например "каталог" и в ней уже и компонент каталога и состояние каталога . Кроме фич в архитектуре приложения понадобятся дополнительные слои, например для объединения всех фич в единый флоу (app), для стандартизации ui - библиотека ui-kit или просто утилиты - вот они и образует "слои" с названиями какие вам будут понятнее).
FSD очень сильно распиарена и переоценена). В большинстве случаев достаточным будет:
1. Понятное распределение файлов по известным директориям: redux, components - ui-kit, hooks, contexts, api.
2. Умение писать понятный, чистый код. Декомпозировать, выносить логику в хуки.
Привет. То, что ты написал имеет смысл. В большинстве случаев это идеально подойдет. Но есть и правда очень загруженные проекты, работа с которыми вызывает сильную головную боль без правильной организации. Опять таки каждый сам для себя выбирает как и с чем ему работать. Главное, чтобы было удобно)
Если у тебя проект небольшой то фсд создаст больше проблем чем пользы, но как только проект становится более или менее большим и в папке components будет хотя бы 50 компонентов тогда начнутся проблемы, на мой взгляд фишка фсд в уменьшении связанности файлов. У этой методологии есть проблемы с переходом на нее потому что привыкнуть к ее сущностям и легко определять что к чему относится бывает не так просто
@@vovka_goodwin +++
Спасибо, большое.
👍
Спасибо! У тебя хорошая подача материала. Полезно и для PM'ов.
Всегда пожалуйста) Забегай, если что, посмотреть будущие видео) ✊
Действительно хорошая подача.
Вот только бы еще проверка озвученной информации была бы подтверждена реальной практикой автора канала.
Пересказ доков и формальный пример минимальной сложности может привести любой))
8:55 - "для тех кто только напичает..... может показаться сложным и непонятным" - я тебе больше скажу, я в разработке много лет и если бы я не знал эти архитектуры я бы ничего не понял из видео, особенно слово "срезы" что это вообще такое )))))
А, понял, ты дословно с английского перевел slice. Не нужно так делать, нужно адаптировать слово ))) Так как в английском могут быть еще другие значения: a part or share of something, especially an amount of money
Обе архитектуры не жизнеспособны на крупных, развивающихся проектах:
В первой проблема постоянных скачков между частями приложения, что в случае работы более 5 человек в параллели выльется в трэш с мержами.
Во второй запаришься компоненты из папочки в папочку перекидывать. И это с учетом того, что паттерн был разработан для юай библиотек, а не для проектов.
расскажите, куда смотреть?)
@@atmaliveзависит от ситуации - не бывает идеальной архитектуры, которая все решает.
1. В любом случае накосячите с выбором архитектуры и придется менять/переписывать и т.д. все собственно как и с кодом
2. Имеет смысл всегда думать о базовых вещах:
а. Бизнес логика всегда отдельно от презентационной логики (это про вью и контроллеры, фабрики, сервисы - можно назвать как угодно, смысл в том, что если есть возможность разделить ответственность - ее необходимо разделить)
б. все связанное с конкретной задачей должно быть в одном месте (есть у вас фича и все по этой фиче должно быть в одной папочке (древе папочек), исключение - переиспользуемая часть, НО с переиспользлванием нужно быть аккуратным, если много условий в одном месте - значит это уже не переиспользуемый функционал, а разный, который почему-то смержили в одном месте - и лучше иметь 10 разных копий, чем одну, но с кучей условий)
в. Вся группировка базируется только и только на основе задач, которые решает та или иная часть приложения (не по размеру как атомик, не по группам, как в базовом мвс, а именно по логичным человеческим задачам)
В целом все равно любую архитектуру потом исправляют докручивают. Главное знать основы, а дальше думать, что работает для команды, а что нет.
@@VitaliKarepanauу меня как раз родилась такая проблема, как вы описали в 2.б. решил тупо копировать и добавлять в комплекте функционал под каждую страницу, потому что невозможно было поддерживать переиспользуемый компонент с переполненным функционалом в зависимости от условий пропсов. Дизайнер захотел везде один комплект по сути, но с кучей разных функций дополнительных
Хорошая и чёткая подача, хороший ролик. Особенно порадовало качество звука (сорри, я немного профдеформирован в этом вопросе=))
Мне как шарповому бекендеру периодически бывает интересно как там фронты поживают, что и как пишут и тд)
Привет, огромное спасибо, очень приятно)
а еще совет))) не облайкивать комментарии. Я столкнулся с баном от ютуба за лайки всех комментов к своим видео, якобы за "спам" и не разбанили же ведь(
С папкой App не совсем понял. Зачем там размещать fonts и styles если ты сказал, что общие компоненты должны быть размещены в shared?
Привет. Я подразумевал, что fonts и style у нас являются глобальными, следовательно можем поместить их в слой настроек приложения)
user post wallet это сущности, а в коде эти сущности выглядят как компоненты, которые мы просто храним в папке entities?
Привет. Все, что отображает визуал entities мы храним в ui сегменте
Чем являются entities, если мы говорим о реакт приложении? Компонентами, типами, сторами и экшенами или классами?
Horosho razlojil po polochkam, spasibo.
Pojalusta, rad staratsya) ✊
Спасибо, отличный контент, то что искал!
Привет, рад, что тебе понравилось) Скоро выпущу много всего интересного, забегай ✊
Что за набор иконок в vs code на превью?
Привет. Это не скрин с IDE. Превью мной сделано полностью. Но иконки Material Icons, если вдруг нужно
@@xlok1e-it спасибо)
а покажи внутри реалного проекта . реалном проекте их много. хотел бы посмотреть
Привет. Да, мне уже об этом писали. У них на оффициалтном сайте есть много примеров проектов с их методологией. Но если вдруг будет интересно, то я запишу обзор на один из таких проектов, либо попробуем сделать декомпозицию, только дайте знать)
Опа, давно хотел про fsd узнать))
А разве такие компоненты как форма для добавления поста, поле добавления комментария, а так же кнопка с лайками не уходят в фичи? По идеи они как раз отвечают за действия.
Привет, да. Сами инпуты являются переиспользуемыми компонентами, а уже функционал для добавления поста или написание комментария отнесем в фичи, это действия пользователя. Возможно я неточно донес свою мысль, прошу за это прощения, постараюсь быть внимательнее
@@xlok1e-it В целом хорошо всё объяснил! Это я просто нюанс хотел уточнить)
привет, а как называется пак иконок который в превью?
Привет. Превью я сам делал, так что пака с иконками такого нет) Но иконки взял из material symbols, может пригодится)
Можешь рассказать пожалуйста бро, если сделать сайт на чистом реакт используя компоненты и т.л., можно ли это назвать веб приложением?
Привет! Веб-приложение это по сути лишь программа, которая выполняется на веб-сервере и доступна через браузер. Использование компонентов позволяет создавать интерактивные и динамичные пользовательские интерфейсы. Так что да)
@@xlok1e-it спс за ответ чувак, очень помог
слой processes яляется устаревшим же и в документации написано, что его лучше не использовать больше
Привет! Да, в закрепе об этом сказано
Хорошее видео. но когда распределял куда что соотнести. сказал, что карточка поста это виджет, но по докам это ui элемент entities. так как относиться к сущности поста.
Привет. Спасибо за твой комментарий, я и в правду ошибся
Очень хорошо всё пояснил! Благодарю!
Большое спасибо ✊
Это с другой стороны не очевидная архитектура, вы в видео post, вынесли в виджеты, кто то выносит его в entities
И еще такой вопрос, вы в виджеты вынесли отдельные блоки, но в таком случае, где будет лежать общий для всего приложения layout ? Явно уже не в виджетах, ведь он не может импортировать компоненты с собственного слоя
а nuxt какую архитектуру использует?)
Я с Nuxt не работал. Но предполагаю, что FSD можно и к Nuxt адаптировать, но там могут возникнуть конфликты.
Очень классные видосы,возобновил изучение фронта, очень мотивируешь:) продолжай в том же духе:)
Спасибо✊
привет, классный видос ) расскажи больше про разные виды архитектуры и архитектуры на беке, и отличается ли архитектура на react native
Привет, большое спасибо!) По поводу архитектуры: в планах записать более подробное видео. Про архитектуру на бэке подсказать не могу, в данной области не специалист к сожалению) И да, FSD можно и с react native интегрировать, не проблема)
Чувак, очень классный видос, я сейчас пишу новый проект, как раз думал разобрать эту методологию, подписываюсь на тебя со всех свои акков
Привет. Огромное спасибо за поддержку, это правда невероятно приятно. Скоро запишу ещё много полезного, забегай) 🙌
Видео крутое, автор молодец !
Спасибо)
Хорошее видео. Молодец!
Привет. Спасибо за поддержку, приятно)
кто сказал, что это правильная структура frontend приложения?
Привет. Понятие правильная на самом деле у всех свое. Я рассказал про данные структуры, основываясь на своем коммерческом опыте и опыте других фронтенд разработчиков. Сейчас FSD используют практически все крупнейшие компании. И, вероятно, когда ты придешь в какой либо большой проект, в его стэк будет входить данная методология. + Она одна из самых удобных
А какая правильная?
я сказал, вопросы?
А кто сказал, что не правильная?
Я сказал.
Было бы классно если ты бы рассказал какие есть недостатки в atomic design
Привет. Писал об этом с своем телеграмме. Лови ссылку сразу на этот пост - t.me/xlok1e/21
FSD не подходит по enterprise app
Как называется методология и является ли это методологией где следующая архитектура:
1. Components (shared), переиспользуемые (кнопки, инпуты, лэйаут) может функции с хуками ещё
2. Pages - собранные страницы, со своими папками компонентов, которые сделаны под эту страницу.
У меня в чем проблема: компоненты вроде одинаковые,но вариация использования большая, то иконка добавляется в дроплист, то он мультипл ,а не соло, то модалка для создания или редактирования объекта, то такая же модалка, но только для просмотра. Пытался сделать с кучей пропсов для переиспользования, но в итоге компоненты так были переполнены функционалом, что решил идти по выше описанной методологии
А как функционально реализовать FSD? Условно у тебя в фьючерсках поставить лайк, и как ты перекинешь эту фьючерс в пропсы?
Состояние должно лежать в Редаксе или любом другом глобальном хранилище. Например entity -> post -> model -> тут слайс редакса и работа с ним
Привет! В Features твоя задача реализовать механику постановки лайка и через public api экспортировать его и использовать уже далее в проекте. FSD это методология по которой ты будешь структурировать файлы в проекте, а как ты реализуешь дальнейшую работу зависать уже от требований проекта. Если вдруг какие то нюансы вызовут трудности, то в описании есть ссылка на документацию - она очень подробная и на русском языке!)
А лично мне проще воспринимать атомик, т.к. есть чёткое понимание структуры и функционала приложение и конкретный список "видов страниц".
Атомик не специализируется на приложениях со сложной бизнес логикой, а так очень даже хорош
Спасибо за объяснение, только на 9:10 вопрос про дублирование UI компонентов, что если есть одна и та же кнопка в post и user. Дублировать код?
Привет, спасибо за вопрос. UI-сегмент является уникальным для конкретного среза, то есть содержащаяся в нем логика не должна использовать больше нигде. Если у тебя есть одинаковая кнопка в разных срезах то она по своей сути является переиспользуемым компонентом. В крайних случаях можно дублировать логику, зависит от ситуации, но лучше максимально такого избегать
@nan-simon вытащи кнопку в фитчу, если она содержит бизнес логику. Для ui компонента сущности сделай пропс типа ReactNode. И по месту использования на уровни виджета или страницы сделай композицию сущности с фитчевым пропсом.
Без обид. Но, в видео вы просто пересказали(содрали) то, что написано на первых страницах документации FSD. Смысла данного видео не понимаю.
Привет. Возможно мне стоит более подробно разобрать на примере данную методологию
@@xlok1e-it, да на примере какого-нибудь мини приложения было б не плохо. В русском сегменте проектов с архитектурой не видел. Будет + огромный. Тот же самый приславутый todolist
В fsd папка processes устарела
Привет. Да, ты прав. Я об это не сказал в видео. Сейчас его уже не используют
Нет я не веб-разработчик, но мне интерестно что тут происходит.
Думаю даже если это не удобная стркутура, то хотя бы будет стандарт, из-за которого будет легче ориентироваться в проекте
Да, каждый всегда для себя что-то найдет) Что касательно удобства - то лично для меня и для многих других фронтенд разработчиков, в том числе из крупных организаций, данная методология очень упростила поддержку проекта в долгосрочной перспективе. А так, я всегда считаю, что надо делать так, как удобно лично тебе, однако забивать на такие факторы, как поддержка и масштабируемость - не лучшая перспектива)
Полезно, спасибо
Всегда пожалуйста) Заходи еще посмотреть если что, вскоре запишу много всего интересного ✊
спасибо за видео
Рад стараться) Надеюсь, что было полезно. Заходи если что ещё, вскоре будет немало интересного 🧑💻
Есть для некста туториал с фсд?
Привет. Разработчики на сайте оставили вот такую статью - feature-sliced.design/ru/docs/guides/tech/with-nextjs. Тут как раз про конфликты FSD + Next и как их избежать
Так и не понял, где же лежит бизнес логика? Неужели во фронте все думают только о том, как правильно файлы по папкам разложить?
Привет. Бизнес логика распределяется по нескольким слоям. К примеру Features реализует бизнес-логику взаимодействия пользователя с приложением. Но например Pages отвечает только за отображение страницы, а бизнес-логика переносится на нижележащие слои
Думаю есть альтернативный ответ на это вопрос, взял из доки, речь о сегментах: model - модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
5 лет разрабатываю на реакте. Понятие архитектура - довольно абстрактное. То что здесь рассказано - это организация директорий и файлов. Причем организация довольно запутанная и неочевидная. Никогда не буду ее применять и уж тем более советовать кому либо
11 минут уделено FSD
1 минута уделена Atomic'у
А в остальном хороший разбор FSD.
Не ну это подписка!
Спасибо за поддержку!)
Спасибо Большое
Пожалуйста, скоро запишу ещё полезностей, забегай)
Больше спасибо за объяснение!!! Все предельно понятно❤
Спасибо за комментарий, рад стараться. Удачного изучения 🔥
Слой процессов дерекейтед уже почти год)
Привет! Да, мне уже об этом писали. Не упомянул об этом в видео. Хотел рассказать про все слои, так что включил его в материал
Processes помечены как deprecated
Привет, это так. В видео забыл упомянуть. Написал об этом в закрепленном комментариии
О вау удачи тебе
Спасибо большое ✊
я вот что понял на практике, на маленьких проектах лучше не внедрять fsd😂
Привет! Ты прав, в маленьком проекте может принести больше вреда, нежели пользы. С другой стороны, если в будущем на проект есть планы, то методологию можно внедрять постепенно, а не сразу)
Привет, не мог бы ты рассказать о себе в какой ты компании работаешь?
Привет. Спасибо, что поинтересовался. С недавних пор нигде не работаю. С головой ушел в контент: ютуб, телеграмм. Времени на это уходит не мало, поскольку хочу сделать качественно)
NX, вот где истина
Предлагаю такой подход:
1) applications. Тут все понятно, если у вас есть допустим форум и магазин, глупо их делать в одной app, хотя и в разных проектах тоже не всегда хорошо, ведь могут существовать множественные связи.
2)Название может быть разным, допустим Features. Отвечает за конкретный функционал: товары, заказы, корзина.
3.1)модели: понятно
3.2)data-access: сервисы, которые загружают наши модели из сервера
3.3)pages: понятно, конкретнве страниця,
3.4)components(widgets): тоже понятно.
3.5)ui (только представления, без подгрузки с сервера)
3.6) разные другие сервиса (гуарды, интерсепторы...), Могут быть перенесены на слои повыше.
В общем, между этим и показанной структурой очень много схожего
Мне кажется образовательные каналы надо помечать какой то меткой , которую нужно заслужить... А то очень много субъективного мнения, а плохих роликов ещё больше
Привет. Все четко, но совет на будущее от проф оператора - не делай 60 кдров)) ни к чему
Привет, спасибо)
Достойно
Благодарю🔥
Заходи если что ещё посмотреть, вскоре запишу много всего интересного)
так авторизация это процесс или фича?
На схеме у тебя auth находится в processes, а потом в примере из документации авторизация это фича
Привет. Слой процессов устарел, об этом в закрепленном комментарии написал. Использовать его больше нерационально. Следовательно авторизация - фича.
Далеко не лучших)
ужОссс
Какая-то каша на первый взгляд. Интересно глянуть какой-нить маркетплейс с этой структурой
Привет, у них на официальном сайте есть примеры различных приложений с использованием FSD, там можно глянуть)
пук-пук среньк fsd 🥱
Мда, компетенция ру девов, как всегда, низкая.
сколько нужно опыта чтобы понять это? ну не могу же я юыть таким тупым...
Привет. Понимание чего-либо всегда приходит на практике) Если ты сейчас чего-то не понимаешь, то не стоит убиваться и пытаться насильно забить себе голову. Пробуй, создавай и спустя время все встанет на свои места!
FSD - самая бездарная архитектура. 👎