Принцип разделения интерфейса. SOLID для React

Четвертый принцип SOLID призывает нас максимально упрощать интерфейсы для компонентов, чтобы в дальнейшем изменения в приложении не привели к избыточному рефакторингу, а также чтобы сами компоненты были переиспользуемыми.
Мои курсы по вебу с купонами:
✅ mishanep.com/
📢 Поддержка канала:
/ mishanep
www.tinkoff.ru...
paypal.me/mish...

[@АлексейСтепанов-к9о]

Спасибо за ваши уроки, Михаил. Объясняете сложные вещи простыми и понятными словами. 👍👍👍

[@IT-Svyatoslav]

Благодарю Михаил за такой подробный контент с примерами 😊

[@BenjaminSergushin]

Подписан давно и не понимаю почему так мало подписчиков!!! Один из самых лучших в плане обьяснения тем. Затрагивает почти все инструменты как фронта так и бек !!! Ваш канал мастхев для джуниора и мидла

[@nikolaysmolov8031]

Как и всегда! Чётко, коротко, без воды, на реальных примерах, доходчиво, с хорошей подачей голосом! Михаил, спасибо!

[@АлександрЮсюз-я8м]

Большое спасибо за эту прекрасную серию уроков, успехов вам Михаил

[@nepcz]

Спасибо Михаил за серию этих видео

[@_GyG_]

Класс! Спасибо за объяснение в контексте реакта)

[@egorpobylets6597]

Спасибо! Отличное видео о SOLID и о принципе ISP

[@danilkladnitsky]

Очень круто!!

[@MrChestermen]

Очень круто и полезно, спасибо Вам Михаил

[@Arablinka]

Только вчера начал смотреть серию этих уроков, а тут еще и четвертый урок) лайк однозначно!

[@sergeymaksimov3441]

Спасибо за видео!

[@olegdegterov1595]

Михаил, спасибо! Ждем 5 принципа D.

[@profesor08]

Если не перепишешь компонент юзер, то будешь переписывать компонент, где этот юзер выводится. В одном месте принцип соблюли, в другом породили проблему. А все потому, что поменялось само апи, сам интерфейс. Он не должен был меняться, он должен был рашириться (Open closed Principle). И тогда не было бы проблем.

[@mishanep]

Видео было скорее про то, что изначально имело смысл проектировать плоский интерфейс, чтобы в дальнейшем на уровне компонента не было нужды в рефакторинге при изменениях вовне. А также чтобы проще было переиспользовать.

[@MAXIMUSICBEST]

++++++ полностью согласен, сталкиваюсь с этим каждый день в работе

[@profesor08]

@@mishanep ну ок, отвертелся xD

[@ValentinProtasevich]

спасибо большое!))

[@ozevas]

Ура! Новое крутое видео ❤️

[@daniilthegunner843]

Спасибо за солид! Но у меня какое-то расплывчатое понимание все равно. "Толстые интерфейсы необходимо разделять на маленькие и специфичные" - звучит как будто также как и определение первого принципа, в котором говорится, что все должно быть разделено и отвечать сугубо за свой функционал. То есть у меня в голове нет какого-то конкретного разделения на все эти принципы, такое ощущение, что они плюс-минус все про одно и тоже)

[@yoshimitsu7723]

первый принцип, как вы и сказали все должно быть разделено и отвечать сугубо за свой функционал, а второй - разделение интерфейсов, указывает на то, что дочерний компонент не должен зависеть от деталей родительского, s и i вроде ни чем не схожи

[@user-888azim-97]

очень жду про последний принцип, потому что буквально на той неделе мой тимлид сказал что у меня неостаточное понимание инверсии зависимостей😳 посмотрел мой компонент и помержил ничего не объяснив, мы просто забили, потому что он нигде не будет переиспользоваться. якобы я поставила используемые методы во главу всего.. в общем, вот посмотрю выпуск, заряжусь, и отрефакторю компоненту! но это не точно)

[@sergey_zatsepin]

Почему не спросила тимлида как нужно было, референсы и т.п.? Мб он ваще загнался сам, без пояснений тем более, странная история. Или у вас не принято общаться просто - итс вэри БЭД ВЕН

[@yoshimitsu7723]

раньше думал, что на оборот лучше прокидывать сразу целый объект чтобы не засорять компонент лишними пропсами

[@AndKozinsky]

Спасибо за пояснения, полезная тема! Михаил, а в Реакте вообще используется ООП? Сколько не писал и максимум что делал это объекты с методами. А в классах так таковой нужды не было потому что данных хранятся в Состоянии или Хранилище. Я делаю что-то не так или ООП в Реакте не требуется?

[@mishanep]

Сегодня нет жесткой необходимости в использовании ООП вкупе с Реактом. Никто не мешает писать и сами компоненты на классах, и сервисы создавать в ООП стилях, но сам Реакт от нас ничего такого не требует.

[@mishanep]

Ну разве что error boundary только на классовом компоненте до сих пор можно написать.

[@Михаил-я9с]

Михаил, в Mobx нам советуют разименовывать свойства максимально позже. Выходит, что при использовании этой библиотеки, мы вынуждены нарушать 4-й принцип?

[@mishanep]

Я не работаю с MobX, никак не могу прокомментировать

[@Виталий-ъ7й8ю]

Михаил благодарю за серию видео по теме... Есть вопрос, на который мой уровень знаний не позволяет дать однозначный ответ... Если коллективный разум поможет буду искренне благодарен... Объявляю класс, прописываю в нём методы без реализации и свойства. Подразумеваю, что он будет являться интерфейсом. Далее в наследниках реализую необходимую логику методов. В коде использую исключительно свойства и методы, объявленные в родительском классе (как бы интерфейсе). Вопрос: это правильный подход/путь в чистом js? Какие-то подводные камни есть у такого подхода?

[@mishanep]

Как вам сказать, ну нет у нас в JS ни интерфейсов, ни абстрактных классов. Получится, что изначальный класс с методами без реализации может иметь детей, у которых будет сломан функционал. Здесь тогда уж лучше в сторону TypeScript посмотреть.

[@Виталий-ъ7й8ю]

@@mishanep спасибо огромное Михаил за отзыв... Понимаю что не самое подходящее место для подробного обсуждения, но позволю себе дополнить... Читаю книгу про паттерны, но в ней всё на java. Я придумал себе повторять материал, но на js - играюсь так сказать... Всё получается и работает, и поэтому у меня и возник вопрос чем мой подход мне грозит... Я не пытаюсь изобрести велосипед, но, насколько я понял ts компилируется в нативный js, поэтому мне интересно применять концепции ООП на чистом js. Однако из-за недостатка знаний в полном объеме, не могу понять чем мой вариант в корне отличается от настоящих интерфейсов и абстрактных классов... Я в родительском классе (который "типа интерфейс") в методах пишу "throw new Error("Метод не реализован")... Это чтобы код основной программы не ломался... А в наследниках уже "перезаписываю" методы под нужную задачу... Вроде все работает... Вроде и полиморфизм получается и композиция... Так в чем мой путь не верен? Если закрыть глаза на отсутствие строгой типизации в js, какие подводные камни меня могут подстерегать? Я же не самый умный)))) вот и не могу сообразить почему все твердят об отсутствии интерфейсов в js, когда этот подход реализуется так, как я описываю... Наверное, я "не догоняю" чего-то))))

[@promoabys]

@@Виталий-ъ7й8ю сорян, много букв, тут лучше уже ссылку на код или скриншот и отправить в специализированный чат

[@firewatermoonsun]

Тогда props drilling будет нарушением этого принципа?

[@NeoCoding]

блин, че раньше не посмотрел.. я наоборот с точки зрения того, что может придется расширять дочерний запихивал обьект целиком чтоб каждый раз не дописывать отдельные пропсы и типы.. но видимо мыслил не в ту сторону?

[@georgegrinding1793]

На 5:00 компонент принимает объект props, но мы вытаскиваем только { items }. При этом этому items устанавливаем тип VideoListProps, тут всё верно? Даже если деструктуризация, то типизация указывается для всего props?

[@mishanep]

Да. Это тоже самое что const MyComponent = ({ items } : { items: Array}) => {} Но так, к счастью, никто не пишет))

[@georgegrinding1793]

@@mishanep Понятно, спасибо

[@quick6response]

6:56 а что если условие вынесли в сам компонент и там проверять это стрим это или видео? Или это и будет уже нарушать принципы?

[@mishanep]

А потом появится третий тип, для которого тоже поддержка обложек понадобится, причем совсем в другом участке приложения, и тогда снова переписывать?

[@strapochek798]

думаю такой код невозможно будет переиспользовать просто, а значит придется либо менять компонент, что противоречит solid, либо создавать новый, но это не лучшая практика, я уверен

[@CJIu3eHb]

В принципе, работы по проверке внутри компонента отображения все-таки несколько больше же (ветвление ифами или свичом), чем в родительском компоненте по вытаскиванию конкретного свойства из сущности и указывания его в пропсе. Но это не главное, ведь мест, где придется менять код при изменении интерфейсов сущностей, столько же - придется менять или в отображении или в родительском (в этом плане первый пример с юзером не убедителен, если проблема только в изменении интерфейса юзера и не планируется отображать никакой другой сущности). Но если использовать отображение для разных сущностей (как во втором примере), то возникают нюансы: - логика сдвигается вглубь дерева компонентов, отдаляется от места основной работы с ней, заползая в компоненты отображения; - и начинается нарушаться как раз обсуждаемый принцим разделения интерфейсов, это показано на 5:50, ведь для того же пропса video надо будет писать в интерфейсе Video | LiveStream | ЕщеЧегоНибудь. Интерфейс со временем будет распухать.

[@enenotowitch628]

2:09 - 4:22