Как разделить код на React компоненты правильно | Эволюция моего подхода | Компоненты по SOLID
HTML-код
- Опубликовано: 27 июн 2023
- Когда был юнцом, разделял компоненты по принципу количества строк кода. Сейчас всё совсем по-другому. Есть прекрасные принципы SOLID, которые дают более качественные критерии, на основе которых нужно проводить разбиение.
Подписывайтесь на мой telegram канал:
t.me/cleanfrontend
Доска в Миро: miro.com/app/board/uXjVPqszse...
01:44 Как я писал раньше
03:55 Преимущества и недостатки подходов
07:34 История с проекта
09:40 React query
12:39 Плоская структура
16:50 Пример кода
19:10 Преимущества плоской структуры
23:48 Недостатки 
Наука
Как мне нравится, как этот молодой человек рассказывает много интересных вещей и иногда шутит. Мое почтение.
Очень годные видосы подряд, спасибо! Давно не было чего то нового и полезного в ютуб сегменте.
Евгений, очень крутой ролик спасибо Вам большое!
Пока не видел ничего подобного, очень хорошая подача. Лайк, подписка
И на каждое видео думаю "где же ты был раньше". Спасибо огромное!
На самом деле это база, но самому сложно дойти до каких-то вещей. Ты ускоряешь этот процесс. Спасибо за твой опыт и что делишься им.
Лайк! Спасибо за контент!
Лайк за то, что понимаешь, что такое srp. Редко такое можно встретить у тех, кто пытается в solid в русском сегменте ютуба
Имхо, финальный подход актуален только для небольших проектов. А также ожидаются проблемы с переиспользованием компонентов (когда ты всё сам написал тут проблем нет, но вот когда приходит новый человек, проблемы уже появляются).
Попробуй взглянуть на Feature-Sliced Design. Я лично её полноценно ещё не использовал, но выглядит самым продуманным вариантов из тех, что я видел.
Я вроде говорил в начале видео, что этот подход на нижнем уровне применяется. Условно в рамках одного fsd сегмента
Они не противоречат, но хорошо друг друга дополняют
Тоже подумал про fsd, также слышал, смотрел, но сам проектов на нем не делал
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Привет! Назидательный контент. Скажи, плиз, что думаешь о FSD архитектуре?
Есть ли примеры кода из видео на гитхабе?
Большое спасибо за отличный контент!
Вопрос. А чем композиционный компонент отличается от простого компонента? Или композиционный компонент - это вы еще и контейнером называете? Разъясните, пожалуйста
Композиционный компонент не несёт в себе никакой логики, а является связующим элементом между всеми остальными элементами и хуками. Между бизнес логикой, отображением, инфраструктурой
Отчасти, это эволюция подхода «компонентов контейнеров»
@@paromovevg Спасибо за ответ. Если будет возможность, мне интересно было бы послушать о видах компонентов, эволюции и так далее. Или может быть порекомендуете какой-нибудь ресурс по этой теме?
@@albert.bazaleev тема очень неразвитая в информационном поле. Обязательно сделаю отдельную систему, о которой расскажу в своих видео
@@paromovevg Буду очень рад. То, что не развито - это в точку.
Я, например, начал выделять такую категорию компонентов как "Layers" - слои. Немного похоже на то описание, которое вы привели. Слои - это компоненты-контейнеры. Обычно они логики не имеют. Слои я использую для группировки и управления отображением крупных логических частей страницы. Слои также могу объединить в абстракцию LayerGroup. Логика слоев появляется тогда, когда нужно показывать только "активный" слой и автоматически скрывать другие слои из группы. Самый простой пример применения слоев - это, например, слой Прелоадер, слой Рабочая область (после прелоадера) и так далее. Слои активно можно использовать при создании табуляции.
Я очень рад что появление react-query (ныне tanstack/query) выправило мозги многим реакт-разработчикам, мне было очень больно смотреть на все эти "прыжки с переподвыпердами" разаботчиков на redux (я сам довольно мало на нём писал).
Видос супер, правда как говорится - "только Ситхи всё возводят в абсолют", так что прямо форсить всё делать на рендер-пропсах, чтобы было супер-гибко, наверно излишне, но пользоваться этой техникой определённо стоит.
ну. это здорово. А теперь попробуй перенести состояние в стейт менеджер. И в каждом компоненте селектить только нужные ему данные. Визуальные конфиги оставь в пропсах, бизнесовые - в sm
Ты обнаружишь что суперхук стал не нужным, он заменился на суперстейт, лишние ререндеры исчезли, и твой композиционный компонент стал в 2 раза меньше.
И, кстати да. Суперхук ведь у тебя огромный получается. Саги нужны именно для упрощения таких суперхуков/суперстейтов, т.с. декларативности мутаций состояния :)
Я вроде не разу не говорил что получается супер хук. Если использовать React-query React-hook-form то 90 процентов сложности улетучивается. Оставшаяся сложность спокойно решается несколькими хуками которые отвечают за свою часть
У любого sm есть проблема неконтролируемого доступа к нему из компонентов. Когда ты напрямую селектишь из компонентов то что надо, твои компоненты начинают зависеть от данных sm, что и нарушает srp.
Если сохранять srp то композиционный компонент останется таким же, только будет брать данные не из хука а из sm. Разницы 0. Я не ругал sm в принципе. Просто мне он для моих задач не нужен ни разу
@@paromovevg Раскрой, пожалуйста, часть про то, что чтение из State Manager нарушает SRP. Я соглашусь лишь отчасти - в глобальном сторе не должно жить локальное состояние компонента. Перенос же глобального состояния в кеш react-query по сути является вариацией State Manager. Но как зависимость от чего-либо нарушает SRP?
Также возникает ощущение, что речь о приложениях, в которых почти вся логика живёт на сервере.
@@paromovevg хм. окей. Тогда так:
гдето снаружи лежат универсальные Button, Avatar и т.п. Это чистые функции.
В бизнесовом компоненте есть обёртки над универсальными. В простейшем случае они подписываются на селекторы и передают полученные данные в пропсы универсальных компонентов. Ты вроде говорил о таком, как о "мини композициях"
Есть главный композиционный компонент, который просто импортирует мини-композиции и собирает их вместе. Сам он от стейта не зависит.
Так мы получаем разбиение на небольшие компоненты, независимость V от M, отсутствие лишних ререндеров.
Что думаешь?
Я говорил что нарушение SRP идёт если обращаться к SM напрямую из компонентов. Так как мы начинаем зависеть от этого стора, тем самым добавляем новую причину для изменений.
Если обращение к SM идёт через тот же композиционный компонент проблем не будет
Просто в большинстве моих проектов чаще всего при правильном применении react-query и react-hook-form остаётся мало "бизнес логики" на фронте что бы использовать SM, вместо хуков
Но важный момент что не во всех. У меня есть проекты в который и redux и mobx были оправданно использованы
Ты лучший
Очень годный контент.
А можно ли где-то найти вот эти схемы из миры? Я б сохранил
Вот ссылочка miro.com/app/board/uXjVPqszseg=/?moveToWidget=3458764558196342735&cot=14
Ui kit ? + приклад
Еще подсказкой про разбиение на компоненты может стать БЭМ методология
серьезно? бэм? просыпайтесь уже
@@true227 многие его используют, что не так?
Советую накидать пример немного посложнее - скажем страницу карточки товара какого-нибудь озона, или карточки фильма из кинопоиска.
Сразу всплывет, что "композиционный" компонент должен состоять из других "композиционных", которые в свою очередь должны также состоять из "композиционных" с другими "композиционными". И попытка все это передавать через пропсы и чилдрены превратится или в гигантское мега-дерево в рутовом компоненте, или останется точно-также поделить все на замкнутые компоненты со своими зависимостями, каждый из которых будет тянуться к нужной ему части стейта (неважно откуда), как уже было раньше при других подходах.🙃 То есть текущий подход по сути ничего и не решает.
Когда какой то компонент сложный, он начинает логически делиться на фичи|модули|домены, правила взаимодействия которых это уже отдельная архитектурная задача.
В данном случае описано низкоуровневое разделение, как не создавать сложности на ровном месте, при этом сохраняя ясность и гибкость
Просто если у тебя простая карточка 3 - 5 уровней вложенности, то сложная это 10 - 15, что просто невозможно поместить в мозг
В данном подходе, по моему опыту, для средней сложности приложений страница спокойно описывается 3 - 4 уровнями композиции
При том, что каждый уровень это свой уровень абстракции
(уровень приложения/страниц/фич/сущностей, это если по fsd)
Делай таймкоды пожалуйста
Ребят, стараюсь. Но времени и сил, часто на это уже не остаётся
Как при таком подходе обстоят дела с тестированием?
По отдельности все компоненты юнитами отлично тестируются
Композиционные компоненты трестируются интеграционными (что логично)
@@paromovevg Если я правильно понял суть метода, бизнес-логика вынесена в довольно крупные хуки. Не возникло ли сложностей с тестированием хуков, возвращающих сразу несколько свойств и методов? Насколько тяжело писать и переписывать тесты к ним? Насколько много приходится мокапить? Как обошли проблему того, что для тестирования хуков довольно часто нужно опираться на их имплементацию (как минимум, учитывать зависимости)?
Про размер хуков в данном видео, я не особо распостранялся. На самом деле они не большие. Композиционный компонент их тоже композирует.
Опять же если захотеть хуки сделать более тестируемыми можно сделать инверсию хуковых зависимостей
Не знаю в курсе ли ты, но есть фоновые помехи в звуке и надо чёт с этим делать )
Подход с контейнерами - зло
Когда в композиционном компоненте прокидывается сразу все и во все места - где тут SRP?)
Это как раз чет вроде god object
Единственная ответственность - композиция других компонентов.
В любом случае кто то это ответственность на себя берёт, в ООП это делают DI контейнеры, а у нас в реакт, для этого должен быть специальный компонент
Важно именно не смешивать композиционную логику и другую
@@paromovevg это жонглирование определениями, у SRP нет четких границ
У DI другая задача, хотя идею я уловил, но каких-то профитов не вижу, выглядит как усложнение структуры на ровном месте при меньшей гибкости
Вы используете данный подход при очень большой вложенности? Не стреляют ли в ноги бесконечные слоты?
@@paromovevg с разделением композиционной логики это хорошо, только сами композиционные компоненты могут использоваться на разных уровнях абстракции и в этом же нет ничего страшного
"доходило до 800 строчек" - поржал))) компонент на 800 строчек на моей работе считается отревьювнутым))
Ага, если число не пятизначное, то в принципе с этим можно пока жить😂
Кажется что ты в итоге пришел к такой же сложности как и была на этапе redux и миллиона селекторов. Самая главная беда этого подхода что ты его придумал сам, и он не имеет широкого распространения, с таким подходом в большой команде не поработаешь, онбординг, документация, правила и тп.
Посмотри в сторону Feature Slice, наверное сейчас это единственное более менее логичное и стандартизированное напрfвление в построении фронтенд архитектуры.
Что это за канал? 100 видео за 1 месяц 😅 это перезалив ?
У меня просто челлендж снимать видео на ютуб каждый день, 90 дней подряд 😅
May the force be with you ;) я кажется не нашел описания о тебе сколько лет ты разработчик? Или где-то есть видео на канале ?
@@JimHoliday22002 около 5 лет
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
мистер ЭкстримЦоде передает тебе привет