7 ms·

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

by jozan 11y ago

shangxiao 11y ago
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.0-beta-1.html#mixins https://facebook.github.io/react/blog/2015/01/27/react-v0.13... [2] https://github.com/brigand/react-mixin https://github.com/brigand/react-mixin
- egeozcan 11y ago
  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"?
  - STRML 11y ago
    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/examples/es6/app.js#L11 https://github.com/STRML/react-router-component/blob/master/...
    - egeozcan 11y ago
      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?
      - STRML 11y ago
        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/lib/RouterMixin.js#L9 https://github.com/STRML/react-router-component/blob/master/... 2. https://github.com/STRML/react-router-component/blob/master/lib/environment/index.js#L12 https://github.com/STRML/react-router-component/blob/master/...
        egeozcan 11y ago
        Ah, now I get it, you meant nested mixins. Great, thanks for the pull, hope it gets merged.
      - STRML 11y ago
        I've submitted a fix for this in react-mixin here. https://github.com/brigand/react-mixin/pull/22 https://github.com/brigand/react-mixin/pull/22
sahat 11y ago
Meh, mixins are anti-pattern and I am glad they are finally gone. In my experience mixins just make your code hard to read.
- MrOrelliOReilly 11y ago
  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.
  - Lazare 11y ago
    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.
    - kyleashipley 11y ago
      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.)
      - Lazare 11y ago
        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. :)
lukasm 11y ago
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 (?)
- eskimobloood 11y ago
  You can at least try decorators with babel using[1] $ babel --optional es7.decorators or 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 https://babeljs.io/docs/usage/experimental [2] http://raganwald.com/2015/06/26/decorators-in-es7.html http://raganwald.com/2015/06/26/decorators-in-es7.html
adjohu 11y ago
Most stuff I've seen is using decorators to enhance components (which seems like a better practice than mixins)
drapper 11y ago
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.
davedx 11y ago
I've been working on a ES6 composition-based library that might help out here: https://www.npmjs.com/package/fabricant 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 :)
inglor 11y ago
Mixins are being considered for ES2016: https://esdiscuss.org/topic/about-lightweight-traits https://esdiscuss.org/topic/about-lightweight-traits meanwhile you can Object.assign behavior into things.
crossman 11y ago
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 https://www.npmjs.com/package/mixin-decorator edit: a link would be helpful, right?

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

by jozan 11y ago

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

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.0-beta-1.html#mixins https://facebook.github.io/react/blog/2015/01/27/react-v0.13... [2] https://github.com/brigand/react-mixin https://github.com/brigand/react-mixin

egeozcan 11y ago
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"?
- STRML 11y ago
  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/examples/es6/app.js#L11 https://github.com/STRML/react-router-component/blob/master/...
  - egeozcan 11y ago
    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?
    - STRML 11y ago
      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/lib/RouterMixin.js#L9 https://github.com/STRML/react-router-component/blob/master/... 2. https://github.com/STRML/react-router-component/blob/master/lib/environment/index.js#L12 https://github.com/STRML/react-router-component/blob/master/...
      - egeozcan 11y ago
        Ah, now I get it, you meant nested mixins. Great, thanks for the pull, hope it gets merged.
    - STRML 11y ago
      I've submitted a fix for this in react-mixin here. https://github.com/brigand/react-mixin/pull/22 https://github.com/brigand/react-mixin/pull/22

sahat 11y ago

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

MrOrelliOReilly 11y ago
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.
- Lazare 11y ago
  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.
  - kyleashipley 11y ago
    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.)
    - Lazare 11y ago
      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. :)

lukasm 11y ago

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 (?)

eskimobloood 11y ago
You can at least try decorators with babel using[1] $ babel --optional es7.decorators or 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 https://babeljs.io/docs/usage/experimental [2] http://raganwald.com/2015/06/26/decorators-in-es7.html http://raganwald.com/2015/06/26/decorators-in-es7.html

adjohu 11y ago

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

drapper 11y ago

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.

davedx 11y ago

I've been working on a ES6 composition-based library that might help out here: https://www.npmjs.com/package/fabricant 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 :)

inglor 11y ago

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

crossman 11y ago

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 https://www.npmjs.com/package/mixin-decorator edit: a link would be helpful, right?