no-mixins.md

ember/no-mixins

💼 This rule is enabled in the ✅ recommended config.

Using mixins to share code appears easy at first. But they add significant complexity as a project grows. Furthermore, the Octane programming model eliminates the need to use them in favor of native class semantics and other primitives.

For practical strategies on removing mixins see this discourse thread.

Rule Details

This rule disallows importing a mixin. This is different than no-new-mixins, which disallows creating a mixin (e.g. Mixin.create({})). Both should be used in an app that wants to disallow the use of mixins.

Examples

Examples of incorrect code for this rule:

// my-octane-component.js
import Component from '@ember/component';
import FooMixin from '../utils/mixins/foo';

export default class FooComponent extends Component.extend(FooMixin) {
  // ...
}

// my-component.js
import myMixin from 'my-mixin';

export default Component.extend(myMixin, {
  aComputedProperty: computed('obj', function () {
    return this.isValidClassName(obj.className);
  })
});

Examples of correct code for this rule:

// my-utils.js
export function isValidClassName(classname) {
  return Boolean(className.match('-class'));
}

export function hideModal(obj, value) {
  set(obj, 'isHidden', value);
}

// my-component.js
import { isValidClassName } from 'my-utils';

export default Component.extend({
  aComputedProperty: computed('obj', function () {
    return isValidClassName(obj.className);
  })
});

References

• Mixins Considered Harmful
• Why Are Mixins Considered Harmful?

Related Rules

• no-new-mixins