With regard to Liskov: on the one hand, you could see your component as accepting props that require certain fields, but entirely allow that the input has more fields than those. On the other hand, if we take the functional html as the output of your component, then your 'red button' will function just as well anywhere that a regular button would have worked.
So in relation to constraints of the information that is passed around, React does seem to inherently follow the L in SOLID.
In the second case the location/context where you use RedButton would not need to be aware of the difference between a Button and a RedButton, so you'd be able to use a RedButton anywhere where you'd otherwise be able to use a Button (-> conforms to LSP there, I would think).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
With regard to Liskov: on the one hand, you could see your component as accepting props that require certain fields, but entirely allow that the input has more fields than those. On the other hand, if we take the functional html as the output of your component, then your 'red button' will function just as well anywhere that a regular button would have worked.
So in relation to constraints of the information that is passed around, React does seem to inherently follow the L in SOLID.
I think the problem is, that you have to do this actively.
if you just do
The
RedButton
only behaves as aButton
in respect to theonPress
handler.You would have to do
to get all the props.
In the second case the location/context where you use RedButton would not need to be aware of the difference between a Button and a RedButton, so you'd be able to use a RedButton anywhere where you'd otherwise be able to use a Button (-> conforms to LSP there, I would think).