Comment by kyleashipley | Hacker News Reader

Comment by kyleashipley | Hacker News Reader

Parent Full thread

I don't think that avoiding mixins implies inheritance. The more common pattern, at least in React, is "higher-order" or "wrapper" components where the responsibility for managing the mixin's behavior is moved into a separate, composable component.

The main issue with mixins is that the origin of behavior becomes opaque. If I call this.mixinFunction(), it's not defined in my file or imported directly, so I have to know exactly which functions come from which mixins. With higher-order components, you can just look at the props and know where things originated.

I'm not a staunch defender of any particular approach, but I think that's the main argument against mixins. (And it applies to other languages as well, such as Ruby.)

Mmm, not sure I see a huge difference between:

    import Foo from './foo';
    let Bar == React.createClass({});
    Bar = Foo(Bar);
    Bar.mixinFunction();

and:

    import Foo from './foo';
    let Bar == React.crateClass({mixins: Foo});
    Bar.mixinFunction();

In both cases I'm adding functions to my Bar component; in neither case is it defined in my file or added directly.

It is true that in the general case the mixin approach would mutate the internal state of Bar, whereas the higher-order component approach would re-render Bar with updated props, which is a solid win for the latter style. (Conversely, a mixin can check the state of the underlying component, while a higher-order component cannot, which means that you can't really implement shouldComponentUpdate as a higher-order component.)

But it's really a fairly subtle difference, and I wouldn't say that either is particularly more transparent. :)

Reply on news.ycombinator.com