项目中经常使用Mixin组件来复用一些业务逻辑，但是它们有一些未定义的细微差别，在项目开发中越来越明显。我偶尔也会遇到这样的情况，它们使代码库的重构或新功能的开发变得困难。在介绍我的方法之前，我想描述一下使用mixin的优缺点。优点扩展了代码重用的DRY原则。我们可以在不同的组件中重用相同的业务逻辑。我们可以将mixin视为全局mixin，与所有组件共享上下文。缺点使用mixin的组件逻辑不透明。在可重写上下文中，我们一定要注意不要重写某些Mixin的同名方法、getter或数据；缺点不是避免混入的关键原因，但我们应该意识到它们。建议采用基于这些技术的方法来减少缺点的影响。在方法、getter、值和道具名称的开头使用前缀。它展示了mixin相关的功能。使用这个技巧可以让我们轻松地分离组件props和mixinprops。例如：$_<(prop|method|value)>。导出默认{props:{$impressionsMixin_page:{type:Number,required:true},$impressionsMixin_listingId:{type:Number,required:true},$impressionsMixin_itemId:{type:Number,required:true}},data(){返回{$impressionsMixin_observer:null,$impressionsMixin_timeout:null,$impressionsMixin_eventObject:null};},方法：{$impressionsMixin_getObserverOptions(){//...},$impressionsMixin_setImpressionObserver(){//...},$impressionsMixin_resetImpressionObserver(){//...},$impressionsMixin_logImpression(){//...}}};在父组中这样使用：我不喜欢在全局mixins中使用前缀通常，这些方法和值的名称是没有歧义的，并且它们的功能在项目的其他部分没有重复，所以没有需要给他们加上前缀。exportdefault{config(){//...},user(){//...},isMobile(){//...},isTablet(){//...},isDesktop(){//...}};这种方式的优点：Mixins的方法或属性可以方便地被IDE自动补全使用。使用前缀可以防止组件方法意外覆盖混合方法和属性。大型项目开发者对组件代码的阅读透明方便。总结Mixins是一个有用的工具，但它们会使我们的项目更加复杂、不灵活和不透明，尤其是在大型项目中。使用这种方法是一种很好的做法，可以明确mixin的含义，避免一些歧义导致的错误。作者：knaagar译者：前端小智来源：medium原文：https://medium.com/@artem.holinka/use-vue-js-mixins-in-a-better-way-11e4ff774763。
