Are vuex mapGetters even worth using?

Question

So I believe the title introduces my question. Given you're introducing a new dependency in each component you want to use mapGetters in, this adds bloat to your package.

This also means your component is now specifically bound to Vue, which is 1 more thing to contend with were you to port components over to another framework like React.

Consider these 2 computed property lists:

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

vs

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

Sure the latter is a tad bit more verbose, but nothing overly bad. You've still got all your getter data the same way in either scenario. To be this seems like totally unnecessary fluff for the small benefit of saving a few characters.

The former example weighs in at 207B (201 characters)

while the later example weights in at 207B (201 characters).

To me that means in terms of type savings, there's virtually none to be had. However I do concede that the former is more readable, portable and ultimately easier to maintain as your relevant data is all in 1 spot.

Answer 1

There are a couple of things that I think are worth mentioning here, regarding an opinion you have on the helper function like mapGetters

• About your code being tightly coupled to vuex should you decide to import mapGetters: it should be clarified that the approach where you access this.$store.getters directly doesn't make your code any less coupled to vuex. After all, such direct access already does assume quite a lot about store's functionalities and how they're exposed to components.

  Take snippets you provided as examples, it can already be seen that your store implementation a) has a concept called getters, and that b) it supports modules such that you can define an interface module like you did.

  Suppose one day, you somehow decide to switch store's implementation to something like puex, which has absolutely no concept of either getters or modules, you will have to refactor all 3 declarations anyway. Or even if you decide to switch to something more advanced like Flure, it will also put you in a similar situation: though Flure has concepts of getters and modules, they aren't exposed the same way vuex does, so you have to edit all 3 lines (again).

  Let alone porting to React, the code you have in computed properties won't even be portable to other store libraries created specifically for Vue. So, really, you shouldn't worry too much about using mapGetters.

• Secondly, for type-saving sake, if you're not going to rename these properties anyway, your mapGetters call can actually be shortened to a one-liner:

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

• Third, once you start having multiple lines of these, it's just easier to track all declarations (e.g., how many getters or state fields you expose from each module). So these helper functions actually helps improve maintainability if used well.

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

• Forth, regarding bundle size, on second thought I believe this might be the main reason why people downvoted you. So, I'll try to explain:

  The thing you need to understand is that real-world production webapps these days use build tools like webpack to create javascript bundles. And because of that, javascript you wrote can be pretty much regarded as source code, which is totally different from the code shipped in a bundle. The reason why they are so different is that the bundle can utilize both minify and gzip techniques to achieve drastic improvement in file size (usually more than 70% size reduction in practice).

  In other words, for webapps these days, javascript is not being served as-is, but almost always be processed by webpack or the like. So, all the character counting you have been doing on the source code isn't going to make a noticeable difference to the final bundle size at all. And because of this, some people might regard your concern as an extremely bad form of micro-optimization, hence their downvotes.

  If I were you, I will try to embrace these helper functions as much as possible, and look at the bundle size after automatic build optimizations before worrying about the bundle size at all. And even if the final bundle size is too big to your liking, I can almost guarantee you won't gain much from mapGetters refactoring, as it's usually other stuff that substantially bloats the bundle size (like a view component library, for example). Really, premature optimization on vuex isn't really worth your trouble.

So, to me, these functions (mapState, mapGetters, mapActions, mapMutations) are definitely worth using.