How to split store in different files? And the limits of object type inference

[nicolidin]

Hello,

I would simply like to split a store in different files and especially to make my different store parts (state, getter, actions) able to inherit from interface, abstract classes, etc..
Furthermore, splitting parts of a Pinia store seems to break the this usage.
As Pinia seems to not really be typed (cause it is only based on object type inference), we just can't split the different parts of a store.

I really wonder why Pinia didn't do like vuex-smart-module allowing to have strong typing through classes usage and to use directly the type of each parts of a store without creating redundant Interface types.
People easily say, "oh classes usage like in vuex-smart-module is more verbose cause you have to specify generics", but when you have to use State, Getter or Action TYPE, you clearly don't want to write/specify n interfaces with k methods for each part a store.

It is common for a lot of projects with strong architecture to have for requirement the need of an abstraction between different parts of different stores.
Example two instances of store like:
ProjectResourceStore and HomeResourceStore having each one Action inheriting from the same abstract class AResourceActions.
What is really useful is that AResourceActions allows having default implementations and specifying a "contract".
ProjectResourceAction and HomeResourceAction will be obligated to implement all non-implemented AResourceActions methods.

What I say above seems to be clearly impossible with Pinia as it has only object type inference.

It's also important to understand that with classes if I want to have a Type of a store part (State, Getter, Action), I don't have to manually specify all the properties/methods in a redundant Interface that will be used as a way to have non-infered type.
Indeed, with classes, I can directly use the class as a Type.

This problem has already been mentioned here: #343, but my issue just try to expose the problem with other related issues and limitations of Pinia type system.
Also, no satisfying code example in the original issue has been provided.

[posva]

It would be nice to document how to split the store into multiple files or functions when needed but the problem has always been mentioned without code samples. It is crucial that real-world examples are provided to better understand what kind of splitting is needed.

So far I identified these possibilities:

• Splitting actions or getters into functions that receive everything needed as parameters (Store type or ReturnType<typeof useStore> could be useful)
• Splitting a store into smaller stores
• Using a setup store to split the store into smaller functions that are composables

[posva]

Regarding the class types, that's a completely different paradigm and, like vuex-smart-module, it should exist in a separate package. I don't use vuex-smart-module but you seem to like it very much, you should write a similar plugin for pinia!

[exbotanical]

It would be nice to document how to split the store into multiple files

This is a considerably prevalent design pattern (using Vuex 4 currently) for my team, and we'd like to continue using it.

So far I identified these possibilities:

• Splitting actions or getters into functions that receive everything needed as parameters (Store type or ReturnType<typeof useStore> could be useful)
• Splitting a store into smaller stores
• Using a setup store to split the store into smaller functions that are composables

@posva Have you had the chance to try any of these options you've listed? I'm just curious if anyone has figured out a clean way to implement this before I deep dive this weekend. I'd be happy to (attempt to) contribute if supporting this pattern is indeed a direction you'd like to go in with Pinia.

In any case, I'm super impressed with Pinia and look forward to adopting it across our projects over the next year!

[rzym-on]

Maybe I'll put something, that will be usefull to this discussion. So far I came across with this example that is working well for me with pinia store.

It is crucial that real-world examples are provided to better understand what kind of splitting is needed.

And according to this, I provided a real-world example. I have some common CRUD getters and actions that I want to use in multiple stores.

baseCrud.ts file:

import axios from 'axios';

export interface CrudState {
  loading: boolean;
  items: any[];
  apiUrl: string;
}

export function crudState(apiCollectionUrl: string) {
  return (): CrudState => ({
    loading: false,
    items: [],
    apiUrl: `http://localhost:8080/api/${apiCollectionUrl}`,
  });
}

export function crudGetters() {
  return {
    allItems: (state:CrudState) => state.items,
    getById():any {
      return (id) => this.allItems.find((x) => x.id === id);
    },
  };
}

export function crudActions() {
  return {
    async initStore() {
      this.loading = true;
      const { data } = await axios.get(this.apiUrl);
      this.items = data;
      this.loading = false;
    },
    async clearAndInitStore() {
      this.items = [];
      await this.initStore();
    },
  };
}

taskStore.ts file in same directory:

import { defineStore } from 'pinia';
import { crudState, crudGetters, crudActions } from './baseCrud';

export default defineStore('tasks', {
  state: crudState('tasks/'),
  getters: {
    ...crudGetters(),
    // Your additional getters
    activeTasks: (state) => state.items.filter((task) => !task.done),
    allItemsCount(): number {
      return this.allItems.length;
    },
  },
  actions: {
    ...crudActions(),
    // Your additional actions
  },
});

using taskStore in main.ts file in same directory:

import useTaskStore from './taskStore';

// Autocompletion works fine here
const taskStore = useTaskStore();
taskStore.initStore();
const count = taskStore.allItemsCount;
const task = taskStore.getById(1);

[posva]

This was added to #829

[aparajita]

Just a followup on this. The example provided by @rzym-on may run, but it fails under strict type checking. After a massive amount of sleuthing into the pinia types, I finally figured out how to split up a store into multiple files and preserve complete type checking. Here we go!

First you need to add this utility somewhere in your project. Let's assume it's in @store/:

extractStore.ts

import type {
  PiniaCustomStateProperties,
  StoreActions,
  StoreGeneric,
  StoreGetters,
  StoreState
} from 'pinia'
import type { ToRefs } from 'vue'
import { isReactive, isRef, toRaw, toRef } from 'vue'

type Extracted<SS> = ToRefs<
  StoreState<SS> & StoreGetters<SS> & PiniaCustomStateProperties<StoreState<SS>>
> &
  StoreActions<SS>

/**
 * Creates an object of references with all the state, getters, actions
 * and plugin-added state properties of the store.
 *
 * @param store - store to extract the refs from
 */
export function extractStore<SS extends StoreGeneric>(store: SS): Extracted<SS> {
  const rawStore = toRaw(store)
  const refs: Record<string, unknown> = {}

  for (const [key, value] of Object.entries(rawStore)) {
    if (isRef(value) || isReactive(value)) {
      refs[key] = toRef(store, key)
    } else if (typeof value === 'function') {
      refs[key] = value
    }
  }

  // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
  return refs as Extracted<SS>
}

Now create a directory for the store. Let's assume it's @store/foo. These files go in the directory:

state.ts

export interface State {
  foo: string
  bar: number
}

export const useState = defineStore({
  id: 'repo.state',

  state: (): State => {
    return {
      foo: 'bar',
      bar: 7
    }
  }
})

getters.ts

import { computed } from 'vue'
import { useState } from './state'

export const useGetters = defineStore('repo.getters', () => {
  const state = useState()

  const foobar = computed((): string => {
    return `foo-${state.foo}`
  })

  const doubleBar = computed((): string => {
    return state.bar * 2
  })

  return {
    foobar,
    doubleBar
  }
})

actions.ts

import { useState } from './state'

export const useActions = defineStore('repo.actions', () => {
  const state = useState()

  function alertFoo(): void {
    alert(state.foo)
  }

  function incrementBar(amount = 1) {
    state.bar += amount
  }

  // Note you are free to define as many internal functions as you want.
  // You only expose the functions that are returned.
  return {
    alerttFoo,
    incrementBar
  }
})

Now you can bring all of the pieces together like this:

import { extractStore } from '@store/extractStore'
import { defineStore } from 'pinia'
import { useActions } from './actions'
import { useGetters } from './getters'
import { useState } from './state'

export const useFooStore = defineStore('foo', () => {
  return {
    ...extractStore(useState()),
    ...extractStore(useGetters()),
    ...extractStore(useActions())
  }
})

Boom! Completely typed and nicely factored. You would then import it like this:

import { useFooStore } from '@store/foo'

const store = useFooStore()
let foo = store.foo // 'bar'
foo = store.foobar // 'foo-bar'
let bar = store.doubleBar // 14
store.incrementBar(3) // store.bar === 10
bar = store.doubleBar // 20

Enjoy! 😁

[Grawl]

@aparajita thank you! but how to access getters inside of actions?