Hacker News Reader

Comment by jozan | Hacker News Reader

What's the status of mixins? How could I do something similar in terms of functionality in ES6?

You have 3 options if you want mixin behaviour:

- Use old syntax or explicitly add mixin to prototype - Use composition. A bit annoying, because you have to make an extra class

    class OuterComponent extends React.Component {
      render() {
        return (
          <MixinComponent>
            <InnerComponent />
          </MixinComponent>
        );
      }
    }

    class InnerComponent extends React.Component{}

- wait for decorators (?)

You can at least try decorators with babel using[1]

  $ babel --optional es7.decorators

  babel.transform("code", { optional: ["es7.decorators"] });

Here[2] is an article that describes how to use it for mixins

[1] https://babeljs.io/docs/usage/experimental

[2] http://raganwald.com/2015/06/26/decorators-in-es7.html

Possibly decorators proposed for ES7 would be a solution here? Babel and TypeScript already support them.

By the way, TypeScript recently (in nightly) gained support for JSX, so we can now have all of this ES6 stuff + types on top of it.

I wrote a small utility for using mixins with my React components. I've been finding it really useful. The notes assume you're using ES7 decorators. But you could easily use it with ES5/6 syntax by treating it as a normal function and just passing your class to it.

https://www.npmjs.com/package/mixin-decorator

edit: a link would be helpful, right?

Mixins are being considered for ES2016: https://esdiscuss.org/topic/about-lightweight-traits meanwhile you can Object.assign behavior into things.

I've been working on a ES6 composition-based library that might help out here: https://www.npmjs.com/package/fabricant

The idea is you declare which components will be needed and the library takes care of instantiating objects with the necessary components for you. It works something like Unity (the game engine)'s entity-component architecture.

I haven't tried to get it working with React yet though, I've been playing with threejs instead :)

Not yet supported afaik [1]. I've used react-mixin [2] with some success.

[1] https://facebook.github.io/react/blog/2015/01/27/react-v0.13...

[2] https://github.com/brigand/react-mixin

Looks like a great idea, a nice intermediate step while the decorators are not widely used. I wonder what didn't work out as you said "some success"?

We have a few rather complex mixins in React-Router-Component and react-mixin's decorators worked just fine [1]. The only limitation I see now is a mixin that defines more mixins; this currently doesn't work, but there's no reason why it couldn't. I am considering a patch.

1. https://github.com/STRML/react-router-component/blob/master/...

Thank you for the heads up and the example.

> The only limitation I see now is a mixin that defines more mixins; this currently doesn't work

Why and how would you do this?

It's just a nice way to split up concerns. In React-Router-Component, the RouterMixin [1] mixes in the Environment Mixin [2] which allows the Environment to address its own concerns in a separate file and to be included in other, custom components.

1. https://github.com/STRML/react-router-component/blob/master/... 2. https://github.com/STRML/react-router-component/blob/master/...

Ah, now I get it, you meant nested mixins. Great, thanks for the pull, hope it gets merged.

I've submitted a fix for this in react-mixin here. https://github.com/brigand/react-mixin/pull/22

Meh, mixins are anti-pattern and I am glad they are finally gone. In my experience mixins just make your code hard to read.

I never understood this line of reasoning. Isn't composition over inheritance a valid principle, especially in JS land?

Speaking more to the anti-pattern part of your comment, obviously whether or not you think they are hard to read is subjective.

Agreed 100%.

I find inheritance much harder to reason about or even read. Mixins don't always lead to the clearest code, but they're better than all the alternatives.

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

Most stuff I've seen is using decorators to enhance components (which seems like a better practice than mixins)

Reply on news.ycombinator.com