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

151–160 of 205 posts

Re: React: Mixins Considered Harmful

#151

Post by biocomputation »

Bahamut wrote: post #125
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…

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

> 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.

Re: React: Mixins Considered Harmful

#152

Post by asQuirreL »

leogcrespo wrote: post #134

Awesome post Dan, thanks for writing and sharing! One thing caught my attention: >At Facebook, we extensively use traits in Hack which are fairly similar to mixins. Nevertheless, we think that mixins are unnecessary and problematic in React codebases. Here’s why. >Mixins introduce implicit dependencies >Mixins cause name clashes >Mixins cause snowballing complexity When I read these three reasons, I actually felt ide…

Traits and mixins are different. A trait/interface/protocol doesn't generally contain implementation, and when it does, it is based only on other methods in the trait (for things like default implementations), whereas mixins are just fragments of a class implementation with potentially arbitrary dependencies on methods.

So traits document the dependencies that mixins make implicitly.

Traits in typed languages can only cause name clashes if two methods in different traits have the same name and the same type signature. This is immediately obvious, and the compiler will warn you so you can fix it there and then when you try and implement them both for one class. (It also brings into question whether there should be another trait to hold that shared method).

The snowballing complexity that is mentioned stems from all those implicit dependencies: There's no way of knowing what they all could be in a nest of related mixins, whereas the corresponding traits document it and provide a map, of sorts.

Re: React: Mixins Considered Harmful

#153

Post by biocomputation »

danabramov wrote: post #104
iandanforth wrote: post #89

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.

>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 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.

Re: React: Mixins Considered Harmful

#154

Post by biocomputation »

iandanforth wrote: post #126
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…

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.

I totally agree. Upvoted!

Re: React: Mixins Considered Harmful

#155

Post by petewailes »

juanger wrote: post #127
jacobr wrote: post #96

Earlier quoted context omitted.

Component state is hardly considered harmful. What has given you that impression?

not exactly harmful, but in the docs they promote stateless functions by saying: "In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible." See https://facebook.github.io/react/docs/reusable-compone…

That's more because most components are render-focused, which means they're more concerned with props than with state. Of course, a particular render component might also have its own state (imagine a list with pagination for example), which isn't required by any of its parents or siblings.

However, state is something on the whole that's required more often higher than lower in your architecture.

I'm pretty sure that's what they're talking about here. Hope that helps.

Re: React: Mixins Considered Harmful

#156

Post by bschwindHN »

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.

Take a look at Reagent (ClojureScript library) for a breath of fresh air and simplicity.

Re: React: Mixins Considered Harmful

#157

Post by nikki93 »

Why not just prototype inheritance with multiple inheritance? Like Self. The class-instance duality is removed then, and everything is just an editable object. This always made the most sense to me. Then just having the 'universe' be a map of id->obj with prototype inheritance, then editing the universe being reduxy and just a reduce over the objects, with the reduce polymorphised over the object's inheritance (this is the benefit of OO, really, not mutable update)--brings wins of functional, prototype, OO all together.

Re: React: Mixins Considered Harmful

#158

Post by szensius »

msane wrote: post #146
janci wrote: post #95

I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods. React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other…

> easy-to-reason-about redux-style state reducers This buzz phrase "easy to reason about" is so popular in the React world. I feel like I'm the only one who finds it oxymoronic. Especially with regard to Redux, which I think is anything but. Angular 1/2, Ember, Backbone are all pretty "easy to reason about", so much so that it is rarely pointed out.

You are definitely not the only one who has not found Redux "easy to reason about". I think the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications.

Re: React: Mixins Considered Harmful

#159

Post by charlysisto »

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.

Re: React: Mixins Considered Harmful

#160

Post by daliwali »

pka wrote: post #124
daliwali wrote: post #110

Earlier quoted context omitted.

>“How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific. I'm not talking about the what, but why would anyone think of using higher order functions to build user interfaces in the first place. It complicates the use case: building and mutating DOM Nodes. >I think the opposite is true. The abstractions are more powerful when they afford building higher leve…

Higher order functions are not such a complicated concept. Just a function passed to a function. You use functions, right?

Yes, but why is the question. I think that is seriously not given much thought and people just accept man-made complexity as essential. It seems tautological to say that higher order components extend components, but it is only due to the design decisions of the React authors that application code must fit its own paradigm, not the other way around.
Post reply on HN