Using a composable to manage store logic before firing an action for many stores

[Maximus1000]

Hi All,
Posva and crew, thanks for Pinia and your incredible efforts.
Apologies for the long question. Much appreciate anyone who provides any suggestions. My question relates to strategy on how to organize lots of business logic between 10+ stores for a complex use case.

I'm migrating from Vuex to Pinia (and JS to TS) and looking to confirm my strategy is okay of passing a Pinia store from a component into a composable and then calling its exported properties from that composable. My use case is that I like having a composable as a service provider for business logic before calling an action (originally Vuex module now in a Pinia store).

In Vuex, I used a Vue3 composable as a large service hub for dealing with business logic before passing on to an action or accessing a getter, etc. Everything I needed from all modules was named agnostically and consistently, e.g. records, non-specific. All I had to do was know the name of the module, the service provider did the rest as all modules exposed the same behavior. Each main view (e.g. orders, products, patients,) would instantiate that service provider composable and then get access to the appropriate module's exports. The service provider would receive the name of the module as an argument and register the appropriate getters and actions from the correct module, like:

 // composables/appApiService.js
 // where moduleName might be blog_module and registers the appropriate Vuex getters/actions.
  const records = computed(() => store.getters[moduleName + '/records'])  
  const fetchRecords = (params) => store.dispatch(moduleName + '/fetchRecords', params)
  - 50+ other getters and actions.
  - 100ish handlers for all sorts of behavior from inline editing to checking changes in forms.

In this way, my service hub could dynamically register any number of Vuex module actions, etc. I would expose handlers from this composable that would perform various processing before calling the appropriate action, somewhat like a checkpoint/guardhouse between the front-end view or component that was wanting some item, change, or data and the Vuex module. I adapted the above technique from reading comments by LinusBorg on the Vue forums. To be sure, I'm a mid-skill guy, trying to hack my way through fullstack very non-gracefully.

In migrating to Pinia, I found that I can instantiate the correct store in a parent view and then pass that store to a composable service provider like above. Then, if all of my stores use the same agnostic type names (records, fetchRecord, createRecord, haveRecords, etc.), I can call those methods without issue in the composable. I'm also using autoimport as Posva suggests in another discussion.

My strategy then looks like this:

 // views/users.ts
  - parent view, instantiates the appropriate Pinia store.
  - calls the service provider and passes in the store
  const usersStore = useUsersStore()
  const {records, handleFetchRecords,...} = useAppApiService({store: usersStore})

// appApiService.ts
- receives the active store, enables central management of all pre-work before calling store action.
export default function useAppApiService({store}) {
  handleFetchRecords = (params) => {
    // do something before calling the action, or return a promise, etc.
    // where store is actually usersStore and solves my issue (service hub works)
    store.fetchRecords().then().catch()
    // do other things after the action has resolved.
  } 
  ... other methods
 - returns all getters/actions from the active store (this was needed in my old format, likely not here)
}

My Vuex stategy was limited by the fact that I only wanted to instantiate the module instance once and then use provide/inject for child components. This worked well as each primary parent view/page would pass down any needed state, getters, or actions. Whereas with Pinia one store can be dynamically imported any number of places (I think) and the same store instance is available as the store is really now acting like a composable anyway.

I realize that the apiService strategy above duplicates logic and doesn't actually call the API, which I'm still doing in Pinia actions as we did previously in Vuex actions. What it does allow me to do restrict the behavior of actions to only making the outbound request and on success make a store state change. The composable service file consolidates repeated logic for any type of api behavior almost like an MVC fat model skinny controller approach, model in this case being my service provider and controller being the 'dumbish' action. Bottom line is that I'm still struggling to bring all the needed pieces together to create a do-it-yourself enterprise approach that's scalable and maintainable.

I'd appreciate any thoughts any one has regarding a flow pattern for an app that needs 10-20 stores with a lot of repeating logic (e.g. abstracted to a service provider). My use case is healthcare and education. Secondly and finally, is passing an actual store from a component to a composable an okay thing to do or a no-go for some other reason...
Sorry for the length, but hoping that others may benefit from any comments from the community on this as well. Again, thanks for reading and all the best!
-Marcus