This is indeed opposition to inheritance in general, precisely because we tried it, and it doesn’t work great in React apps. React has a strong composition model that does not need inheritance.
https://discuss.reactjs.org/t/best-practices-for-extending-s...
Of course you are free to use inheritance for other purposes. (Or even React components if you insist.) But as the team behind this library, we strongly suggest you to use composition instead of inheritance when defining React components.
In addition, anything a user can accomplish with inheritance, a user can also accomplish with composition, but while retaining flexibility, so when considering how much the UI layer can change in an app, one generally wants that flexibility. Inheritance is more useful when creating low level abstractions or maybe wrappers around such, but should generally be avoided when it comes to consumption for higher order constructs because of the complex chains involved.
* This is what I have found at least - perhaps I'm making some incorrect points. If so, I'd like to know why I'm wrong here, since these are just conclusions I've drawn from experience so far.
Composition has the exact same problem in this respect.
* Object A
* Object B
* Object C
* Object A
* Object B
Now go and write code that has instances of Object C. Can you remove Object A without side effects? The amount of pain you experience from removing Object A from Object C isn't related to composition or inheritance. It's related to how often you use a particular object. Furthermore, if you're a library author, pain and inflexibility can arise from how API customers react to breaking changes ( badly ). In this case, it really doesn't matter whether or not you're using inheritance or composition.
It amazes me how many programmers cannot seem to understand this.
In React, “composition” means has a very specific meaning: it’s putting components into components. It has very little to do with object composition because in React component instances almost never “talk” to each other. They don’t call methods on each other.
React component model is much closer to functional composition which doesn’t suffer from the drawbacks you describe.
If I have an object that inherits, I might say:
Object.Func() // Method implemented by base class.
If I have an object that uses composition, I might say:
ObjectA.ObjectB.Funct() // Using method of Object B.
There are dependencies in both cases. Composition simply changes the way the dependencies are distributed across a set of objects.
* Inheritance is getting something from you parents.
* Composition is getting something from your children.
Both are valuable strategies in systems design. It seems to me that your apparent dislike of inheritance is motivated by the fact that it's currently trendy to dislike inheritance, rather than having any rational / well-reasoned technical motivation.
The article you are commenting on is about avoiding mixins in React components. It is not a general statement saying “Always use anything called ‘composition’ over anything called ‘inheritance’”.
We found that inheritance doesn’t work well for React components. And we found that composing React components with React’s composition model (which has very little to do with object composition) worked well for us.
Nowhere do we claim that object composition is better than object inheritance, or something else generic like this.
(Sorry if you didn’t interpret it this way. I just want to make it clear for future readers that this branch of discussion is not related to the contents of the article.)
https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2...
I wouldn't consider 1995 current. And it's gone way beyond "trendy".
EDIT: Also, what you've mentioned there is not composition - it is objects that have other objects as properties. Composition basically involves wrapping and forwarding, whether it's function or object composition.