Принцип единой ответственности. SOLID для React
HTML-код
- Опубликовано: 29 сен 2024
- Первый принцип SOLID - самый простой в понимании, но самый часто нарушаемый. Разбираемся с принципом единой ответственности и смотрим, что он значит в контексте React-приложения.
Мои курсы по вебу с купонами:
✅ mishanep.com/
📢 Поддержка канала:
/ mishanep
www.tinkoff.ru...
paypal.me/mish...
Очень приятно слушать. Идеальный голос для преподования. Подача контента - отличная. Спасибо за работу)
Главное, не доводить использование этих принципов до абсурда. Как говорил Джек Воробей - "Кодекс - это рекомендации, а не жесткие правила"
Капитан Джек Воробей!
Михаил, всегда с большим удовольствием смотрю ваш образовательный контент. Ваше имя в узких кругах всегда ассоциируется с глубокой экспертизой. Большое спасибо, что находите в себе силы делиться.
Эх как же годно, спасибо большое
Вдохновился видео и зарефакторил 300 строчек в 50;)
круто
Отличный материал и подача.
Ваше место в тим-лидах и менторах.
Только человек который обладает такой эмпатией успешно справиться с этой ролью.
Браво.
Так Михаил ДОЛГОЕ ВРЕМЯ преподавал :-)
@@SergiyAntonyuk_PhD заметно
Эмпатия при межличностном общении проявляется, а не через экран
А как так эмпатию определять?
@@TheProfessionalGambler если у человека самого развита эмпатия - то он лучше и быстрее может понять, кто перед ним, иногда даже только по голосу и манере говорить, хотя, конечно, так легче ошибиться
конечно все правильно. но если используются пару десятков инпутов для создания пачки фильтров с разными данными и функциями при изменении и выборе, то как это разделить?
Расскажите пожалуйста как применяется данный принцип при разработке структуры редьюсеров.
Плодить отдельный редьюсер для каждого отдельного глобально используемого состояния или же объединять их в группы?
Например пользователь выбрал тему сайта, выбрал текущую категорию товаров, выбрал текущую валюту и выбрал текущую ширину экрана своего браузера.
Стоит ли объединить все эти «текущие» в один редьюсер currents с ключами или же для каждого создать отдельный редьюсер и наплодить их с десяток и более ?
Спасибо за видео. Интересная тема!
Мне кажется, основная сложность в применении этого метода - уловить грань между тем, когда компонент остается понятным и читабельным и тем, когда его уже пора дробить на более мелкие кусочки логики.
Понимать «единственную ответственность» в случае с реактом можно по-разному. Например, в реальном проекте изначальный код, скорее всего, остался бы в таком же виде, потому что он вполне понятен и прост. Можно сказать, что этот компонент решает единственную задачу - отрисовывает полученный список задач. Точно так же можно сказать про абстрактный компонент страницы - он отрисовывает одну страницу. Т.е. решает одну задачу, несмотря на то, что логики на странице может быть очень много.
Я думаю, целью в случае с реакт-компонентом должна быть простота логики и относительная краткость, которую можно мерять в условных экранах или строчках кода. Например, принять за правило, что «компонент должен помещаться в 200 строк».
При этом чрезмерное дробление логики может привести к тому, что с таким кодом будет просто неудобно работать.
Но все это сложно формализировать, конечно. Чувство этой «грани» приходит с практикой.
Михаил, спасибо за ваш труд и ваши образовательные видео. У вас отличная подача и отменное качество материала. С нетерпением жду видео о дальнейших принципах SOLID.
Михаил, спасибо за такое крутое объяснение, с примерами и наглядностью! Очень замечательное видео, ждем продолжение. Теперь хочется сделать большой рефакторинг кода в своих приложениях))😀
Интересно как будут натягиваться следующие принципы solid на react. Там все непросто.
Спасибо огромное, а будет и другие принципы SOLID?
Когда возникает у меня вопрос, всегда держу в памяти, что это есть у Михаила на канале и пользуюсь этим как закладкой в книге.
как разруливать, если есть несколько ролей, от которых зависит отображение todo ?
Автор не совсем понимает SRP. Тот же Роберт Мартин отдельно упоминает, что "функция должна делать что-то одно" это отдельный принцип, не относящийся к SRP
Это один из главных принципов, который обязаны применять в проекте. Сейчас работаю над проектом с классовыми компонентами. Прилетает небольшая правка, думаешь часа на два, открываешь компонент….. а там компонент на 2-3 тысячи строк кода и твои два часа превращаются в два дня😬
Почему не рефакторите?
@@sergey_zatsepin некогда. В ту ду по 20 тасок висят
буквально вчера читала на хабре с этими иллюстрациями, роботами. тоже понравились картинки)
Да, Михаил, спасибо.
И отдельное за практический пример,
потому что действительно в теории звучит всё просто,
а на практике это всё превращается тяжело поддерживаемый код
и длинные портянки
Спасибо, отличное видео!
есть еще такое понятие оверинжениринг когда дробят настолько мелко компоненты учитывая что нет переиспользования дальнейшего что очень неудобно рыскать по закладкам собирая эти атомы в молекулы
И да, я бы не отказался в рамках темы послушать о том, насколько разделяет первый принцип паттерн Синглтон, является ли он антипаттерном, и какую роль он играет во фронтенд разработке.
Спасибо за лекцию! Кстати огромный класс/компонент/функция и т.д. называется - God Object. Это антипаттерн.
God он не из за огромности назван был, а за то что делает все подряд, нарушая принцип единой ответственности
Очень классное и полезное видео. Сравнительно недавно все хотел начать изучить эти принципы, но не особо мог найти подходящий материал для изучения. С нетерпением жду нового видео по следующим принципам.
😂300-500 это еще терпимо, а по 2-3к строк компоненты?)))
Очень хорошая подача материала. Жду следующее видео по данной теме SOLID
У Михаила всегда очень полезный контент, для моего уровня
Спасибо за видео, и простой и наглядный пример!
Ооо крутяк!! Спасибо вам огромное
Отдельное спасибо за пример и анимацию, понимание гораздо быстрее приходит) Пойду применять на практике)
дядя Боб в своей книге Чистая Архитектура, как раз пишет об этом, что SRP - это не совсем про то, что наша функция/модуль/класс должна выполнять что-то одно, в его блоге есть целая статья на эту тему
>> And this gets to the crux of the Single Responsibility Principle. This principle is about people.
>> Gather together the things that change for the same reasons. Separate those things that change for different reasons.
>> However, as you think about this principle, remember that the reasons for change are people. It is people who request changes.
Как вы понимаете данные данные цитаты? И как, по-вашему, мы можем применять их в Реакт-приложении, написанном в функциональном стиле?
@@mishanep на мой взгляд не имеет принципиального значения какой стиль/парадигму мы используем, я думаю то, про что Вы рассказываете в своём видео относится больше к рефакторингу, когда мы большие компоненты дробим на более мелкие, что-то выносим, чтобы наша функция/функциональный компонент делал "что-то одно", решал одну задачу. Тут ещё интерсный вопрос, а что значит что-то одно? Как раз функциональные компоненты, по-моему мнению, здесь очень показательны , ведь они не "делают что-то одно" на самом деле, они зачастую инкапсулируют в себе логику, состояние, ещё и перезентационную составляющую, но в реакте это абсолюно нормальный подход. Мартин Р. вводит в SRP такой термин как module, и мне кажется, вот тут и заключается основная идея, в том, что наш модуль (нечто более глобальное) должен иметь одну причину на изменение и этой причиной является конечный потребитель. Если спроецировать это на реакт приложение, у нас может быть, условно, модуль/компонент Калькулятор, который в свою очередь может состоять из други модулей/компонент, к которым мы можем применить те принципы (подходы), про которые Вы рассказываете в видео, e.g. дробление на более мелкие компоненты, вынос логики в кастомные хуки, дробление презентационной части и т.д., а Калькулятор сам по себе должен измениться по требованию потребителя, который этим калькулятором пользуется, что-то вычисляет с его помощью, а если бы наш модуль Калькулятор проигрывал ещё и музыку, то тут мы бы нарушили SRP и у нашего модуля появилась бы ещё одна причина на изменение (от тех пользователей, которые слушают музыку). Я, конечно, могу ошибаться, я не эксперт и себя таковым не считаю, это сугубо моё личное мнение и интерпретация SRP
Спасибо за развернутый ответ. В моем понимании когда мы говорим про изменения функционала, то здесь больше история про open-closed принцип.
Михаил подскажите пожалуйста название утилиты ограничивающая строчки компонентов
Prettier
Большое спасибо, то что нужно!!!
Спасибо большое, очень жду продолжения 🙏🙏🙏
Классную тему подняли Михаил, ждём новых видео, большое спасибо, что помогаете сообществу.
Михаил, спасибо, что делаете такой крутой и полезный контент!
Отличная тема! Спасибо большое за материал!
реально простой пример 🙂
Очень круто!!!!
Михаил, спасибо большое за ваши видео!
Solid Snake
Идем дальше )
Класс, спасибо!
Когда ты говоришь Здраствуйте, меня зовут Михайл Непомнящий, в этот момент я понимаю что что-то забыл. )))
Спасибо, интересная информация. Но и без SOLID (S), точнее этого термина, со временем и так приходит истина что компоненты нужно дробить и чтобы каждый компонент отвечал за что-то одно иначе будет полная каша.
Например, как вы уже продемонстрировали в ролике, никаких запросов fetch/axios не должно быть в компоненте, их все нужно выносить в отдельные папки и файлы. Можно еще привести пример: на многих страницах приложения используется таблицы, тут уже напрашивается, что нужно сделать отдельную компоненту и передавать в нее данные. И тем самым с этой компонентой будет просто работать и модифицировать в будущем (стилизовать, добавить фильтрацию, сортировку и т.п.)
Очень приятный тембр и интонация голоса. Про смысловую составляющую я вообще молчу) Видео смотреть одно удовольствие! Спасибо за труды
Михаил, в основном массиные компоненты получаются,когда есть группа импутов.Понимаю,что громоздкость возможно сократить с помощью мап а данных импутов,но если это разные типы и функции онченджа
7:20
Спасибо
Извиняюсь за занудство, но Бедняга Боб Мартин не устает повторять, что SRP - это про то, что компонент программы должен иметь только одну причину для изменения. Например продажи не могут требовать изменения метода (если им не нравится сумма затрат), который сделан для расчета налогов для бухгалтерии. Это не совсем то, о чем вы говорите. Вы говорите о более широком правиле, что компонент решает только одну задачу. Это не то что подразумевается в первом принципе SOLID. 🤗 Ссылаюсь на книгу Clean Architecture
Всё это, конечно, хорошо. Но как бы вы адаптировали это в реалии Реакт приложения, написанного в функциональном стиле?
Ну ты выдал... Палюбе сам не понял, что написал
Огромное спасибо!!! Для такого дурака как я - это самое доходчивое объяснение 😄
Спасибо за работу. На практике, например контейнер или контролер компоненты, где собирается большая форма с многими кастомными компонентами запросто может набрать пару сотен линий кода.
Только не единая, а единственная. Почему-то многие переводят это не правильно
Спасибо! Отлчиное видео по SOLID по SRP
спасибо! отличное видео, не хватало такого ясного объяснения принципов именно на примере реакта
Мишаня вы супер.
Давайте темы помощнее.
Отличный контент! Большое спасибо!
Оооо сеньёрские штучки пошли в дело! Хорош!
Спасбо большое за видео особенно с примерами про реакт
Спасибо попробую действовать
спасибо вам, отличное видео!
Спасибо. Было интересно
nice xdd
Спаибо за Ваш труд
Топ!
Super!
просто имбааааа
Спасибо
Автор видео сам наверное до конца не понял отчем это принцип, я рекомендую почитать книгу «чистая архитектура», где правильное определение принципа «единственной ответственности» и про что на самом деле этот принцип.
То что компонент, функция и т.д. должны делать что-то одно это не про SRP.
Автор видео старается от себя ничего не придумывать, а делать выжимку на базе существующих материалов на английском языке. Вообще мною было замечено, что как только речь заходит про какие-то принципы в программировании, лучшие практики или (особенно) шаблоны проектирования, то сразу появляется группа экспертов по этим вопросам, считающая что "автор не прав". При этом эксперты могут высказывать противоположные мнения, либо вовсе избегать высказывания своего видения, указывая на матчасть. Безусловно, есть академический подход, когда мы помимо предполагаемой подачи начинаем сравнивать точки зрения, может быть спорить с ними, прилагать источники цитирования. Но в погоне за академичностью можно в итоге ничего не сделать или только запутать тех, кто начинает разбираться в вопросе. По факту я рассказываю о том, что читал сам и в каком ключе это обсуждалось мною с коллегами по проектам. По итогам цикла я скорее всего приложу источники, которыми пользовался при подготовке.
Расскажите вкратце
@@sergey_zatsepin , что рассказывать, открываешь книгу «чистая архитектура» глава III параграф 1.
Во время видео про SOLID вышло. Как раз таки Деда Боба читаю :)
При использовании Material UI или Tailwind уложиться в компоненте в 100 строчек становится непросто.
Ну вообще то принцип называется «принцип единственной ответственности» , а не единой.
Единственный человек от которого я смог понять один из принципов
Продай мне ручку уже устарело, теперь продай мне: single responsobility. Хорошо продал)