title: Vuex Mapping Getter with Argument - Cached?
body: <p>Here is an example of a Vuex Store with a <strong>parameterized getter</strong> which I need to map onto the Vue instance to use within the template.</p>
  
  <p><div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="true">
  <div class="snippet-code">
  <pre class="snippet-code-js lang-js prettyprint-override"><code>const store = new Vuex.Store({
    state: {
      lower: 5,
      higher: 10,
      unrelated: 3
    },
    getters: {
      inRange: state =&gt; value =&gt; {
        console.log('inRange run')
        return (state.lower &lt;= value) &amp;&amp; (state.higher &gt;= value)
      }
    },
    mutations: {
      reduceLower: state =&gt; state.lower--,
      incrementUnrelated: state =&gt; state.unrelated++
    }
  })
  
  new Vue({
    el: '#app',
    template: "&lt;div&gt;{{ inRange(4) }}, {{ unrelated }}&lt;/div&gt;",
    store,
    computed: Object.assign(
      Vuex.mapGetters(['inRange']),
      Vuex.mapState(['unrelated'])
    ),
  })
  
  setTimeout(function() {
    console.log('reduceLower')
    store.commit('reduceLower')
    setTimeout(function() {
      console.log('incrementUnrelated')
      store.commit('incrementUnrelated')
    }, 3000);  
  }, 3000);</code></pre>
  <pre class="snippet-code-html lang-html prettyprint-override"><code>&lt;script src="https://unpkg.com/vue/dist/vue.js"&gt;&lt;/script&gt;
  &lt;script src="https://unpkg.com/vuex/dist/vuex.js"&gt;&lt;/script&gt;
  &lt;div id="app"&gt;&lt;/div&gt;</code></pre>
  </div>
  </div>
  </p>
  
  <p>Firstly, this does appear to be valid, working code. However considering <code>computed</code> is meant to be a cached set of computed properties, I'm curious about the behavior in this scenario, is there caching going on? If there isn't, is there a performance concern to consider? Even though the function does not cause any state change, should it be a <code>method</code>?</p>
  
  <p>Is this an anti-pattern? The example isn't a real one, but I do want to centralize logic in the store.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>I have updated the example to illustrate that modifications to the underlying <code>lower/higher</code> value upon which the <code>inRange</code> getter is based, are indeed reactive for the Vue instance (despite not being mapped as state). I have also included an <code>unrelated</code> value which is not part of the calculation, if the mapped getter were cached, modifying the unrelated value should not trigger the getter to be called again, however it does.</p>
  
  <p>My conclusion is that there is no caching, thus this has poorer performance than a conventional computed property, however it is still functionally correct.</p>
  
  <p>The question remains open as to whether there is any flaw in this pattern, or one available which performs better.</p>