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

Третий принцип SOLID - принцип подстановки Барбары Лисков - один из самых неочевидных в применении в рамках React-приложений. Разбираемся что это за зверь и чем он будет полезен.

Мои курсы по вебу с купонами:

📢 Поддержка канала:

[Teqila]

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

[nikolaysmolov]

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

[nicepingrace]

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

[vlasovdanildev]

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

[unknown.]

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

[Commondore]

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

[egorpobylets]

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

[Armasn]

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

[ocqjvuc]

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

[TheKykp]

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

[NikOroferov]

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

[promoabys]

Михаил, спасибо. Хорошее объяснение.

Да, есть некоторое пересечение со вторым принципом.

И если третий принцип про интерфейсы и наследование, то второй про практику частично опираясь на третий.

В моём понимании получается как-то так.

[_GyG_]

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

[CJIueHb]

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

Для первого варианта подойдет пример с Button (6:55). Для второго варианта - яркий пример с PasswordInput (13:30).

[tpthmtr]

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

[vadicus]

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

[aleksandernikolaev]

Не понял примеры с 8 минуты.

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

[milomans]

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

[baileysli]

Мне кажется наследовать сразу все пропсы, если 90% не будут использованы избыточно. Где-то видел совет выбирать только нужные (через Pick например, чтобы типизация была более явная)

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

[foxyll]

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