Is it intended to split the code into multiple files?

[matthiashermsen]

Thanks for this nice package, good job :)

Given the following sample store using the composition API

import { defineStore } from "pinia";
import { computed, ComputedRef, ref, Ref } from "vue";

export const useStore = defineStore("counter", () => {
  const counter: Ref<number> = ref<number>(0);

  const counterPlusOne: ComputedRef<number> = computed<number>((): number => counter.value + 1);

  // ... many other getters here ...

  function increment(): void {
    counter.value++;
  }

  // ... many other actions here ...

  return {
    counterPlusOne,
    increment,
  };
});

Large projects might have quite big stores so it might be useful to split the state, getters and actions into multiple files. I would like to know if there are any utils to achieve that?

Of course I could implement the logic somewhere else and import these functions but counterPlusOne needs to know about the state variable counter so I would have to pass different state variables to the implementations.

E.g. defineGetter with the generic outcome computed<T>((state: State): T => ...)

[posva]

Usually, you split the store into smaller, more specific stores. Otherwise, thanks to the composition api, you can just split stuff into functions, the same as with components.

[matthiashermsen]

Ah, you mean like so?

https://v3.vuejs.org/guide/composition-api-introduction.html#standalone-computed-properties

[posva]

exactly!
but usually, splitting into multiple stores is better 😄

[matthiashermsen]

Would you mind describing it a little bit?

Let's say you would have a todo app, you would put all the things related to the todos into that. But you might have many getters and actions.

You would split this store into smaller ones dealing with "different business cases"?

[posva]

If it cannot be split into smaller submodules, then I wouldn't split that file. If really necessary, you can split the store like shown in https://v3.vuejs.org/guide/composition-api-introduction.html#standalone-computed-properties.

In practice, if everything belongs to a store and cannot be split, you keep in different functions the bigger parts of the business logic. When you start adding a new feature and it requires a new store, you create it or use an existing store that belongs to that business logic.