Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React: Mixins Considered Harmful

facebook.github.io

Post reply on HN
Print view View original

161–170 of 205 posts

Re: React: Mixins Considered Harmful

#161

Post by vog »

charlysisto wrote: post #159

It's funny to see in the life cycle of every new language/framework in the block the rediscovery of good architectural patterns that can be summed up in one sentence: - inheritance & mixin bad / composition good. Good article nevertheless.

> inheritance & mixin bad / composition good

This wisdom is at least as old as the classic GoF book [1] which was published in 1994. Many of their patterns can be summarized as: "Favor 'object composition' over 'class inheritance'."

They also give a pretty simple, compelling reason for that: It is just a direct consequence of the even more fundamental principle:

"Program to an interface, not an implementation."

[1] Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides): "Design Patterns: Elements of Reusable Object-Oriented Software" https://en.wikipedia.org/wiki/Design_Patterns

Re: React: Mixins Considered Harmful

#162

Post by Vilkku »

jameslk wrote: post #129

That's too bad, mixins were simple to grasp and worked really well. The oft suggested alternative to mixins is higher order components. Here's one of my favorite quotes[0] on the matter: > You lose so much with [higher order components], especially with es6: > You lose the (original) class, and with it, the ability to compose it, to extend it and …. reflection. All your components are [the higher order component]. Fo…

From the article:

> Let’s make it clear that mixins are not technically deprecated. If you use React.createClass(), you may keep using them. We only say that they didn’t work well for us, and so we won’t recommend using them in the future.

Re: React: Mixins Considered Harmful

#163

Post by tomjen3 »

charlysisto wrote: post #159

It's funny to see in the life cycle of every new language/framework in the block the rediscovery of good architectural patterns that can be summed up in one sentence: - inheritance & mixin bad / composition good. Good article nevertheless.

I find that inheritence allows me to save a ton of code, but using it widely does mean you need the ability to refactor, which isn't hard in Java or C#, but can be more of a pain in languages like Ruby.

Re: React: Mixins Considered Harmful

#164

Post by hicksyfern »

biocomputation wrote: post #153
danabramov wrote: post #104

Earlier quoted context omitted.

>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-s... Of course you are free to us…

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 distribute…

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.

Re: React: Mixins Considered Harmful

#165

Post by charlysisto »

vog wrote: post #161
charlysisto wrote: post #159

It's funny to see in the life cycle of every new language/framework in the block the rediscovery of good architectural patterns that can be summed up in one sentence: - inheritance & mixin bad / composition good. Good article nevertheless.

> inheritance & mixin bad / composition good This wisdom is at least as old as the classic GoF book [1] which was published in 1994. Many of their patterns can be summarized as: "Favor 'object composition' over 'class inheritance'." They also give a pretty simple, compelling reason for that: It is just a direct consequence of the even more fundamental principle: "Program to an interface, not an implementation." [1] G…

I would argue that the more intuitive principle behind composition is the "Single Responsibility" one. Although it is correlative to the idea of 'program to an interface' (aka don't mingle with the state from the inside of an object that is not for you to do) I find it easier to grasp.

While i'm at it I'll add that the main reason SRP is so important is because it limits combinatorial explosions of state, so you can keep control, test and reason about it - incidentally the main idea behind the success of React.js

Re: React: Mixins Considered Harmful

#166

Post by biocomputation »

hicksyfern wrote: post #164
biocomputation wrote: post #153

Earlier quoted context omitted.

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 distribute…

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.

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.

Re: React: Mixins Considered Harmful

#168

Post by hicksyfern »

biocomputation wrote: post #166
hicksyfern wrote: post #164

Earlier quoted context omitted.

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.

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.

Currently trendy?

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.

Re: React: Mixins Considered Harmful

#169

Post by macspoofing »

ludwigvan wrote: post #2

I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.

>I believe as time passes, we are moving away from the simplicity that made React win.

Because every framework will handle small simple use-cases beautifully. When you include a codebase with thousands of lines of code, co-developed by many people, you can see where the pain points are.

Re: React: Mixins Considered Harmful

#170

Post by robmcm »

tomjen3 wrote: post #163
charlysisto wrote: post #159

It's funny to see in the life cycle of every new language/framework in the block the rediscovery of good architectural patterns that can be summed up in one sentence: - inheritance & mixin bad / composition good. Good article nevertheless.

I find that inheritence allows me to save a ton of code, but using it widely does mean you need the ability to refactor, which isn't hard in Java or C#, but can be more of a pain in languages like Ruby.

inheritance is very hard to comprehend at a later date, traversing though sub/super class hierarchy, overrides and super calls is incredibly painful.

You often end up with a subclass that may be thousands of lines in length if you consider it's flattened definition.

Post reply on HN