Does initial state work with setup stores for testing/pinia?

[kalvenschraut]

Trying to migrate to pinia and nearly there but hitting issues with trying to mock my setup stores.

I have a userStore that is a setup store. It returns a user ref at the end of the store. Now I want to set the initial value of this user for a test but https://pinia.vuejs.org/cookbook/testing.html#initial-state does not seem to be woriking

#1835 (comment) found this which points in the direction I thought I needed to go, but documentation is not clear about this kind of issues and is the biggest pain point when using pinia.

IMO setup stores fit really nicely with vuejs composition API and would be great if I could set the initial state/getters without having to @ts-gnore the typescript errors.

[posva]

initial state should work for both setup and option stores. Are you sure you are calling useStore() after mounting? like shown at https://pinia.vuejs.org/cookbook/testing.html#initial-state ? Otherwise you will need to pass the testing pinia to the useStore() function. You can see an example at https://pinia.vuejs.org/cookbook/testing.html#mocking-getters although the real explanation is at https://pinia.vuejs.org/ssr/

[kalvenschraut]

Finally getting back to this, thanks for your response!

I think what is tripping me up was me trying to do "userStore" under the initial state instead of "user" which was what I called the store. You do highlight this in the documentation which I apparently missed and on more thought makes sense that it works this way.

For second is that it appears that writeable computed are considered getters and such can't have an "initialState". I would think it would be considered a state variable since a getter is typically not writable.

[posva]

getters are indeed very different from state (not serialized during SSR, not in pinia.state.value, computed from state, ...). You have to set them directly (https://pinia.vuejs.org/cookbook/testing.html#mocking-getters). We could add an option to the testing pinia but I feel like that would be too verbose. I'm open to suggestion ofc

[kalvenschraut]

Seems like you don't want to consider writeable computed as state per #1360.

For me I have a computed property that has a base value off of one other computed and which can be overriden. To override it it uses a local ref variable that is set to whenever the computeds set is called. I don't return this variable at the end of the setup store as I thought it wasn't needed. Seems like only way to override it is to return it so it can be patched.

Example of the computed setup

// from vue use
const { isOnline } = useNetwork();
const isOnlineInternal = ref(true);  
const online = computed<boolean>({                                                                      
    get() {
      return isOnlineInternal.value && isOnline.value;
    },
    set(online) {
        isOnlineInternal.value = online;
    }
});

[kalvenschraut]

Setting like a normal getter works I suppose, wasn't what I initially expected.

[posva]

It's fine to have an internal state. Make sure it's not needed for Hydration if you are using SSR though because since it's not returned, it's not part of the state that is later on serialized by pinia