Принцип разделения интерфейса. SOLID для React
ฝัง
- เผยแพร่เมื่อ 28 มี.ค. 2023
- Четвертый принцип SOLID призывает нас максимально упрощать интерфейсы для компонентов, чтобы в дальнейшем изменения в приложении не привели к избыточному рефакторингу, а также чтобы сами компоненты были переиспользуемыми.
Мои курсы по вебу с купонами:
✅ mishanep.com/
📢 Поддержка канала:
/ mishanep
www.tinkoff.ru/rm/nepomnyasch...
paypal.me/mishanep - วิทยาศาสตร์และเทคโนโลยี
Спасибо за ваши уроки, Михаил. Объясняете сложные вещи простыми и понятными словами. 👍👍👍
Подписан давно и не понимаю почему так мало подписчиков!!! Один из самых лучших в плане обьяснения тем. Затрагивает почти все инструменты как фронта так и бек !!! Ваш канал мастхев для джуниора и мидла
Благодарю Михаил за такой подробный контент с примерами 😊
Большое спасибо за эту прекрасную серию уроков, успехов вам Михаил
Спасибо Михаил за серию этих видео
Как и всегда! Чётко, коротко, без воды, на реальных примерах, доходчиво, с хорошей подачей голосом! Михаил, спасибо!
Класс! Спасибо за объяснение в контексте реакта)
Очень круто и полезно, спасибо Вам Михаил
Очень круто!!
Спасибо! Отличное видео о SOLID и о принципе ISP
Ура! Новое крутое видео ❤️
Спасибо за видео!
спасибо большое!))
Михаил, спасибо! Ждем 5 принципа D.
Только вчера начал смотреть серию этих уроков, а тут еще и четвертый урок) лайк однозначно!
Если не перепишешь компонент юзер, то будешь переписывать компонент, где этот юзер выводится. В одном месте принцип соблюли, в другом породили проблему. А все потому, что поменялось само апи, сам интерфейс. Он не должен был меняться, он должен был рашириться (Open closed Principle). И тогда не было бы проблем.
Видео было скорее про то, что изначально имело смысл проектировать плоский интерфейс, чтобы в дальнейшем на уровне компонента не было нужды в рефакторинге при изменениях вовне. А также чтобы проще было переиспользовать.
++++++
полностью согласен, сталкиваюсь с этим каждый день в работе
@@mishanep ну ок, отвертелся xD
Спасибо за солид! Но у меня какое-то расплывчатое понимание все равно.
"Толстые интерфейсы необходимо разделять на маленькие и специфичные" - звучит как будто также как и определение первого принципа, в котором говорится, что все должно быть разделено и отвечать сугубо за свой функционал. То есть у меня в голове нет какого-то конкретного разделения на все эти принципы, такое ощущение, что они плюс-минус все про одно и тоже)
первый принцип, как вы и сказали все должно быть разделено и отвечать сугубо за свой функционал, а второй - разделение интерфейсов, указывает на то, что дочерний компонент не должен зависеть от деталей родительского, s и i вроде ни чем не схожи
очень жду про последний принцип, потому что буквально на той неделе мой тимлид сказал что у меня неостаточное понимание инверсии зависимостей😳 посмотрел мой компонент и помержил ничего не объяснив, мы просто забили, потому что он нигде не будет переиспользоваться. якобы я поставила используемые методы во главу всего.. в общем, вот посмотрю выпуск, заряжусь, и отрефакторю компоненту! но это не точно)
Почему не спросила тимлида как нужно было, референсы и т.п.? Мб он ваще загнался сам, без пояснений тем более, странная история. Или у вас не принято общаться просто - итс вэри БЭД ВЕН
На 5:00 компонент принимает объект props, но мы вытаскиваем только { items }. При этом этому items устанавливаем тип VideoListProps, тут всё верно? Даже если деструктуризация, то типизация указывается для всего props?
Да. Это тоже самое что
const MyComponent = ({ items } : { items: Array}) => {}
Но так, к счастью, никто не пишет))
@@mishanep Понятно, спасибо
Михаил, в Mobx нам советуют разименовывать свойства максимально позже. Выходит, что при использовании этой библиотеки, мы вынуждены нарушать 4-й принцип?
Я не работаю с MobX, никак не могу прокомментировать
Спасибо за пояснения, полезная тема! Михаил, а в Реакте вообще используется ООП? Сколько не писал и максимум что делал это объекты с методами. А в классах так таковой нужды не было потому что данных хранятся в Состоянии или Хранилище. Я делаю что-то не так или ООП в Реакте не требуется?
Сегодня нет жесткой необходимости в использовании ООП вкупе с Реактом. Никто не мешает писать и сами компоненты на классах, и сервисы создавать в ООП стилях, но сам Реакт от нас ничего такого не требует.
Ну разве что error boundary только на классовом компоненте до сих пор можно написать.
Тогда props drilling будет нарушением этого принципа?
6:56 а что если условие вынесли в сам компонент и там проверять это стрим это или видео? Или это и будет уже нарушать принципы?
А потом появится третий тип, для которого тоже поддержка обложек понадобится, причем совсем в другом участке приложения, и тогда снова переписывать?
думаю такой код невозможно будет переиспользовать просто, а значит придется либо менять компонент, что противоречит solid, либо создавать новый, но это не лучшая практика, я уверен
В принципе, работы по проверке внутри компонента отображения все-таки несколько больше же (ветвление ифами или свичом), чем в родительском компоненте по вытаскиванию конкретного свойства из сущности и указывания его в пропсе. Но это не главное, ведь мест, где придется менять код при изменении интерфейсов сущностей, столько же - придется менять или в отображении или в родительском (в этом плане первый пример с юзером не убедителен, если проблема только в изменении интерфейса юзера и не планируется отображать никакой другой сущности). Но если использовать отображение для разных сущностей (как во втором примере), то возникают нюансы:
- логика сдвигается вглубь дерева компонентов, отдаляется от места основной работы с ней, заползая в компоненты отображения;
- и начинается нарушаться как раз обсуждаемый принцим разделения интерфейсов, это показано на 5:50, ведь для того же пропса video надо будет писать в интерфейсе Video | LiveStream | ЕщеЧегоНибудь. Интерфейс со временем будет распухать.
Михаил благодарю за серию видео по теме...
Есть вопрос, на который мой уровень знаний не позволяет дать однозначный ответ...
Если коллективный разум поможет буду искренне благодарен...
Объявляю класс, прописываю в нём методы без реализации и свойства. Подразумеваю, что он будет являться интерфейсом. Далее в наследниках реализую необходимую логику методов. В коде использую исключительно свойства и методы, объявленные в родительском классе (как бы интерфейсе).
Вопрос: это правильный подход/путь в чистом js? Какие-то подводные камни есть у такого подхода?
Как вам сказать, ну нет у нас в JS ни интерфейсов, ни абстрактных классов. Получится, что изначальный класс с методами без реализации может иметь детей, у которых будет сломан функционал.
Здесь тогда уж лучше в сторону TypeScript посмотреть.
@@mishanep спасибо огромное Михаил за отзыв... Понимаю что не самое подходящее место для подробного обсуждения, но позволю себе дополнить...
Читаю книгу про паттерны, но в ней всё на java. Я придумал себе повторять материал, но на js - играюсь так сказать... Всё получается и работает, и поэтому у меня и возник вопрос чем мой подход мне грозит... Я не пытаюсь изобрести велосипед, но, насколько я понял ts компилируется в нативный js, поэтому мне интересно применять концепции ООП на чистом js. Однако из-за недостатка знаний в полном объеме, не могу понять чем мой вариант в корне отличается от настоящих интерфейсов и абстрактных классов...
Я в родительском классе (который "типа интерфейс") в методах пишу "throw new Error("Метод не реализован")... Это чтобы код основной программы не ломался... А в наследниках уже "перезаписываю" методы под нужную задачу...
Вроде все работает... Вроде и полиморфизм получается и композиция...
Так в чем мой путь не верен?
Если закрыть глаза на отсутствие строгой типизации в js, какие подводные камни меня могут подстерегать? Я же не самый умный)))) вот и не могу сообразить почему все твердят об отсутствии интерфейсов в js, когда этот подход реализуется так, как я описываю...
Наверное, я "не догоняю" чего-то))))
@@user-zf3ze8wn7c сорян, много букв, тут лучше уже ссылку на код или скриншот и отправить в специализированный чат
блин, че раньше не посмотрел..
я наоборот с точки зрения того, что может придется расширять дочерний запихивал обьект целиком чтоб каждый раз не дописывать отдельные пропсы и типы.. но видимо мыслил не в ту сторону?
раньше думал, что на оборот лучше прокидывать сразу целый объект чтобы не засорять компонент лишними пропсами
2:09 - 4:22