Unable to use `direct-vuex`

Describe the bug Because of the way store is initialized, I’m unable to use direct-vuex stores. Short summary, direct-vuex is a “wrapper” for vuex to provide typing for store. Thanks to it you can do this.$store.dispatch.myAction(myPayload) happily.

To Reproduce Steps to reproduce the behavior:

• create store via createDirectStore from direct-vuex.
• result of this function is already a Vuex.Store so initialization in render fails (getters should be function)

Expected behavior

I can use direct-vuex stores.

I’m skipping few sections as I already know the solution (or at least where problem originates):

Problematic code here.

if (store) {
    const Vuex = require('vuex')
    localVue.use(Vuex)
    vuexStore = new Vuex.Store(store)
  }

I do realize why it’s written this way.

Question to the maintainers is, how do you want to implement it. Or whenever you want to implement it at all! There could be boolean switch in additionalOptions to skip store initialization (like initializeStore, by default set to true, to not break API), or some other options like directVuexStore which you can use to add to the Vue instance instead of plain store. I’m happy to help with this in any way you need.

[afontcu]

Isn’t the following an option? I’ve never used direct-vuex before, so I might be wrong:

const increment = jest.fn();
const decrement = jest.fn();

const { getByLabelText } = render(
  ExampleComponent,
  {},  // <-- without importing and passing localVue
  (vue) => {
    vue.use(Vuex);

    const { store } = createDirectStore({
      state: () => {
        return { counter: 0 };
      },
      getters: {
        counter: (state) => state.counter,
      },
      mutations: {
        increment,
        decrement,
      },
    });

    return { store: store.original };
  }
);

[kosciak9]

While I understand your point of view and also dislike this way of testing, sometimes you have to draw a line between units that you’re testing, even if those units are quite huge.

In our case we abstracted any communication with APIs to Vuex, and provide just one or two actions that will check input and refetch accordingly. UI components are decoupled from anything besides looking at fetchState and actual data. That’s why mocked stores are mostly just one getter and one action. It’s a more complicated props setup, that allows us to do this.$store.direct stuff.

I’m not sure if that’s the greatest approach but it allows us to think in smaller blocks (UI, Server) and separate logic.

We do have tests that use our “real” store the way user is using them, but such a big test failing won’t give you quick insight into what have you actually broke.

It’s like they say in Python’s Zen: Special cases aren’t special enough to break the rules. Although practicality beats purity.

I feel practicality here beats purity of DOM testing. 😃