5 ms·

I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common. I'd hate for ES6 to add dec

I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common. I'd hate for ES6 to add decent classes and then have React push people away from 'extends'. But perhaps I'm reading too much into this.

danabramov 10y ago
>I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common. 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-subclassing-components/1820/2 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.
- Bahamut 10y ago
  I would add that there seems to be a push against inheritance in general with UI components in the frontend web app world. React clearly is designed against using it, and same thing with Angular 2 (inheritance does not play well with decorators, which are metadata on specific component classes). I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level, precisely due to the problems of leading developers down the path of creating potentially incorrect abstractions & being too painful to fix when UI can potentially change quite a bit structurally. 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.
  - biocomputation 10y ago
    > I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level, precisely due to the problems of leading developers down the path of creating potentially incorrect abstractions & being too painful to fix when UI can potentially change quite a bit structurally. Composition has the exact same problem in this respect. * Object A * Object B * Object C * Object A * Object B Object C is composed of Object A and 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.
    - danabramov 10y ago
      When people say “composition” they refer to different things. You are referring to object composition. 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.
- iandanforth 10y ago
  This is incredibly unfortunate. I feel like this attitude will turn off and hamper a lot of potential users. It smacks of functional proselytizing and it is not appreciated.
  - biocomputation 10y ago
    I totally agree. Upvoted!
  - danabramov 10y ago
    We are sharing what worked for us. Why would be encouraging people to use patterns that did not work well for us?
- biocomputation 10y ago
  Will using composition help me avoid large, painful refactors if I change the composition of my components? 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.
  - hicksyfern 10y ago
    I don't think you've really read and understood the notion of function composition. All you're talking about here is having objects as properties of other objects - that is not function composition.
    - biocomputation 10y ago
      I'm not asking about function composition, I'm asking if there is any basis for disliking inheritance other than the fact that it is currently trendy to do so.
      - hicksyfern 10y ago
        Currently trendy? https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2C_Chapter_1 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.
      - danabramov 10y ago
        There’s something I’d like to clarify. 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.)

danabramov 10y ago

>I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common. 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-subclassing-components/1820/2 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.

Bahamut 10y ago
I would add that there seems to be a push against inheritance in general with UI components in the frontend web app world. React clearly is designed against using it, and same thing with Angular 2 (inheritance does not play well with decorators, which are metadata on specific component classes). I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level, precisely due to the problems of leading developers down the path of creating potentially incorrect abstractions & being too painful to fix when UI can potentially change quite a bit structurally. 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.
- biocomputation 10y ago
  > I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level, precisely due to the problems of leading developers down the path of creating potentially incorrect abstractions & being too painful to fix when UI can potentially change quite a bit structurally. Composition has the exact same problem in this respect. * Object A * Object B * Object C * Object A * Object B Object C is composed of Object A and 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.
  - danabramov 10y ago
    When people say “composition” they refer to different things. You are referring to object composition. 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.
iandanforth 10y ago
This is incredibly unfortunate. I feel like this attitude will turn off and hamper a lot of potential users. It smacks of functional proselytizing and it is not appreciated.
- biocomputation 10y ago
  I totally agree. Upvoted!
- danabramov 10y ago
  We are sharing what worked for us. Why would be encouraging people to use patterns that did not work well for us?
biocomputation 10y ago
Will using composition help me avoid large, painful refactors if I change the composition of my components? 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.
- hicksyfern 10y ago
  I don't think you've really read and understood the notion of function composition. All you're talking about here is having objects as properties of other objects - that is not function composition.
  - biocomputation 10y ago
    I'm not asking about function composition, I'm asking if there is any basis for disliking inheritance other than the fact that it is currently trendy to do so.
    - hicksyfern 10y ago
      Currently trendy? https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2C_Chapter_1 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.
    - danabramov 10y ago
      There’s something I’d like to clarify. 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.)