vuex mapGetters甚至值得使用吗？

Question

因此，我相信标题会介绍我的问题。鉴于您要在要使用mapGetters的每个组件中引入新的依赖关系，因此这会给程序包增加膨胀。

这也意味着您的组件现在已专门绑定到Vue，如果要将组件移植到其他框架（如React）上，这还需要解决。

考虑以下两个计算的属性列表：

import { mapGetters} from 'vuex'
    computed: {
        ...mapGetters({
          active:'interface/active',
          mode:'interface/mode',
          views:'interface/views',
        }),
    }

与

computed: {
      active:() { return this.$store.getters['interface/active'],
      mode:{ return this.$store.getters['interface/mode']},
      views:{ return this.$store.getters['interface/views']},
}

当然，后者有点冗长，但没有什么太糟糕的了。在任何一种情况下，您仍然都以相同的方式获得所有的吸气剂数据。这样做似乎完全是不必要的，因为节省几个字符的好处很小。

前一个示例重207B（201个字符）

而后面的示例权重为207B（201个字符）。

对我来说，这意味着节省类型，几乎没有。但是，我确实承认，前者更具可读性，可移植性，并且最终易于维护，因为您的相关数据全部集中在一个位置。

Answer 1

关于您对助手功能的看法，我认为有几件事值得在此提及 mapGetters

• 关于代码是否紧密耦合，vuex如果您决定导入mapGetters：应该澄清一下，this.$store.getters直接访问的方法不会降低您的代码的耦合性vuex。毕竟，这种直接访问确实已经对store的功能及其如何暴露于组件承担了很多责任。

  以您提供的摘录为例，已经可以看出您的商店实现a）有一个名为的概念getters，并且b）它支持模块，以便您可以interface像定义模块那样定义模块。

  假设有一天，您以某种方式决定将store的实现切换为puex，而绝对没有getters或的概念，modules无论如何您都将必须重构所有3个声明。甚至即使您决定切换到类似的更高级的内容Flure，它也会使您处于类似的情况：尽管Flure具有吸气剂和模块的概念，但它们的使用方式vuex并不相同，因此您必须编辑所有3行（再次）。

  更不用说移植到React了，您在计算属性中拥有的代码甚至无法移植到专门为Vue创建的其他商店库中。因此，实际上，您不必担心使用mapGetters。

• 其次，出于节省类型的考虑，如果您仍然不打算重命名这些属性，mapGetters则实际上可以将您的呼叫简化为单一代码：

computed: {
  ...mapGetters('interface', ['active', 'mode', 'views']),
}

• 第三，一旦开始包含多行代码，跟踪所有声明（例如，从每个模块公开多少个getters或state字段）就更容易了。因此，如果使用得当，这些辅助功能实际上有助于提高可维护性。

computed: {
  ...mapState('interface', ['list', 'packages']),
  ...mapGetters('interface', ['active', 'mode', 'views']),
  ...mapGetters('foo', ['bar', 'baz']),
}

• 第四，关于捆绑包的大小，第二个想法是，我认为这可能是人们拒绝您的主要原因。因此，我将尝试解释：

  您需要了解的是，当今的实际生产Web应用程序都使用构建工具（例如webpack创建javascript捆绑包）。因此，您编写的javascript几乎可以视为source code，与捆绑销售的代码完全不同。它们之所以如此不同的原因是，该捆绑包可以同时使用minify和gzip技术来实现文件大小的显着改善（实际上通常减小70％以上的大小）。

  换句话说，对于当今的Web应用程序，JavaScript 并不是按原样提供的，而是几乎总是由webpack之类处理。因此，您一直在进行的所有字符计数source code都不会对最终捆绑包的尺寸产生明显的影响。因此，有些人可能将您的关注视为微优化的一种极其糟糕的形式，因此是他们的低票。

  如果您是我，我将尝试尽可能多地包含这些帮助程序功能，并在自动构建优化后查看捆绑包的大小，然后再完全考虑捆绑包的大小。即使最终的捆绑包大小过大，您几乎也可以保证您不会从mapGetters重构中受益，因为通常其他因素会使捆绑包的大小大大膨胀（例如，像视图组件库）。确实，过早的优化vuex确实不值得您付出麻烦。

所以，对我来说，这些功能（mapState，mapGetters，mapActions，mapMutations）是绝对值得使用。