Принцип подстановки Лисков. SOLID для React

[@nikolaysmolov8031]

Класс! Как всегда: информативно, понятно, хорошие примеры - просто клад, а не канал! Михаил, спасибо!

[@vlasovdanildev]

Михаил, каждый день жду вашего видео. Успехов вам!

[@mishanep]

Спасибо =)

[@nicepingrace]

Коллега, у вас самые лучшие видео по React!

[@Teqi1la]

Один из лучших каналов по React и JS в ру сегменте, очень информативные видео, спасибо!

[@Armas0n]

Полезно, обычно об этом принципе, конечно, говорят в контексте джавы, ООП и вот этого вот всего. Крайне интересно было посмотреть на то, как его можно интерпретировать на фронте

[@АндрейКуравлев-л1д]

Спасибо, очень интересное видео. Про Лисков не видел, где бы объясняли еще доступнее.

[@egorpobylets6597]

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

[@Commondore]

Михаил, спасибо за труд! Очень интересное и полезное видео👍

[@TheKykp]

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

[@NikOroferov]

Комментарий приемлемой длины в благодарность за видео

[@unknown.6914]

Чтобы контент Михаила увидело больше людей, напишу этот комментарий и поставлю лайк.

[@promoabys]

Михаил, спасибо. Хорошее объяснение. Да, есть некоторое пересечение со вторым принципом. И если третий принцип про интерфейсы и наследование, то второй про практику частично опираясь на третий. В моём понимании получается как-то так.

[@miloman1995s]

спасибо за урок, подскажите, на 11:02 вот у нас есть комопнент, потом нам понадобилось сделать ProductCard... получается мы используем композицию и импортим BasicCard в новый компонент ProductCard где добавляем какую то новую html разметку и логику и внутри используем BasicCard? правильно ли я все понял? спасибо!

[@mishanep]

Оно может быть по-разному реализовано. В том числе и через композицию. Но основная идея - совместимость по пропсам и ожидаемому набору ивентов. То есть, чтобы при смене компонента можно было передать все те же самые пропсы и ожидать похожего поведения. При этом разметка может быть и другой, когда это требуется.

[@_GyG_]

Спасибо за классный контент! А можно кратенько объяснить, в чем ключевое отличие от принципа open closed? В данной демонстрации, поймал себя на мысли, что если бы вы по этому видео рассказывали все то же самое, но в контексте принципа open closed, я бы и ухом не повел😊 Мы же просто расширяем интерфейсы и при этом не меняем существующие.

[@mishanep]

Хороший вопрос. Расширение возможностей компонента путем композиции не обязывает нас сохранять тот же интерфейс. По необходимости мы закрываем какие-то возможности, хардкодим их. Как например, в случае с PasswordInput. Вероятно в данном случае его пример для третьего принципа не слишком удачный, потому как скорее всего мы захотим ограничить набор входных пропсов (тот же type вряд ли нужно получать). Потом принципы не противоречат друг другу. Они идут рука об руку и говорят как комплексно мы можем подойти к решению своих задач.

[@_GyG_]

@@mishanep Спасибо за ответ. Все-таки сложно понять этот принцип на примере функционального программирования. Точнее, понять то можно, а вот найти отличие от другого принципа не просто. Да и не нужно, это ведь всего лишь слова))

[@promoabys]

Соглашусь и с вопросом и с ответом и ответом на ответ ))

[@CJIu3eHb]

Тут надо определиться, что все-таки значит - успешная подстановка потомка. То ли это точно такой же результат (внешний вид и функционал для компонента), то ли это просто гарантия того, что код не сломается (для полиморфизма). Похоже, что чаще принцип трактуется по второму варианту. Для первого варианта подойдет пример с Button (6:55). Для второго варианта - яркий пример с PasswordInput (13:30).

[@nouchance]

Спасибо большое ✊💯🤝

[@ПрилепскийРоман-и9т]

Спасибо! Супер

[@baileysli6235]

Мне кажется наследовать сразу все пропсы, если 90% не будут использованы избыточно. Где-то видел совет выбирать только нужные (через Pick например, чтобы типизация была более явная) Хотя в целом согласен, что это удобно, когда FC имеют обратную совместимость с базовым HTML. Поскольку многие js`еры не умеют в вёрстку, то неоднократно сталкивался, что хочу использовать html элемент формы, а у кнопок в проекте нет type и они все по умолчанию submit, либо есть type но он используется для вариатов и приходиться городить велосипеды типо htmlType и т.д.

[@mishanep]

У нас нет задачи использовать данный подход для всех компонентов. Здесь скорее вопрос именно подстановки - возможность заменить один компонент на схожий, но более навороченный.

[@aleksandernikolaev4061]

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

[@fiatluxinregnonoctis]

Спасибо

[@JackShepards]

Спасибо, очень круоо

[@ЕвгенийКавецкий-в5ъ]

Thank you

[@boburmustafo]

Spasibo

[@ЕвгенийКулига]

Михаил, спасибо за урок) Должен заметить, что получился хороший пример ООП принципа, который подвязаный к реакту, но все же опять получается, что это работа с классами, ибо интерфейсы это те же классы)

[@vadicus6534]

привет, расскажи нам так же про этот несчастный ООП пожалуйста)

[@foxyl0l]

из увиденого складывается впечатление что этот принцип === наследование, в чем принципиальная разница?

[@mishanep]

Подстановка Лисков и есть о наследовании. С тем нюансом, чтобы не менять наследованные методы. В нашем случае мы не используем наследование классов, но интерфейсы.

[@SlimDwarfPavelIronfoot]

честно я все равно не очень понял, тут использовался typeScript с интерфейсами, а если у нас js тогда что?? то есть мы ушли от функционального программирования и задействовали этот принцип в интерфейсах ... а интерфейсы это ООП...

[@mishanep]

Я бы не стал ставить знак равенства между интерфейсами и ООП. По крайней мере в TypeScript. Нам не нужен класс в JS, чтобы работать с объектом, будь это набор пропсов для Реакт компонента, либо просто навороченный параметр функции. Не нравится интерфейс - то же можно описать через алиас типов. На чистом JS реализовать сложнее. Можно начать с Jsdoc совместно с правилами линтера.

[@SlimDwarfPavelIronfoot]

@@mishanep спасибо за ответ

[@AMith-lv2cv]

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

[@ilyaprotsenko1023]

Такое впечатление, что третий принцип пропагандирует второй принцип (open/closed), но разницы по этому видео не смог ощутить. Третий принцип пропагандирует: "Наследующий класс должен дополнять, а не замещать поведение базового класса" Суть третьего принципа звучит так, как суть второй принципа ( открытости/закрытости ). Может, где-то что-то неправильно понял? Поправьте меня, пожалуйста

[@---Maksim---]

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

[@ДмитрийДымов-е6я]

Какой-то дисонанс с принципом разделения интерфейсов. В котором вы говорите что не надо передавать лишние пропсы. Тут же наоборот пррокидваются все пропсы. Поправьте если я не правильно вас понял