Determine whether or not a pinia store is being actively used by a component.

[tochoromero]

Here is my use case.

We use composition functions to define our stores and we use SWRV heavily, interestingly enough @posva also used it on his composition store example.

Now lets say I have a composition store that uses SWRV to fetch expensive data from my server and it refreshes the data every minute.
The data will not be initially fetched until a component uses the store for the first time, this is good, but because the stores are long lived singletons, the SWRV instance will continue to fetch the data every minute even after the component that originally called the store has been unmounted.

SWRV allows you to pass a reactive function that either returns the key for the SWRV call or null if it should not fetch data. We can leverage this in userland in a couple of ways:

1. Have the stores keep a list of its callers, and have the components that use the store register and unregister from the store when mounted/unmounted. This way we know when nobody is using the store and we can stop the SWRV instance.
   But this adds a burden on the developers and if you forget to register or unregister you will not get the expected behavior.
2. Maintain a list of routes the store is used in, this way if we are on a route that does not need the store we can stop SWRV.
3. Create a composition function wrapper for calling stores that takes care of maintaining a map of stores and callers and automatically adds and removes components from the map.
   I had this working but I couldn't make the typing work, the returned object from the store completely lost its typing and I couldn't figure out how to maintain it.

Now, I believe there is clean solution that can be baked into Pinia itself.
What if Pinia internals maintained a list of callers for the store, this should be possible using the getCurrentInstance function and onBeforeUnmounted hooks. Then somehow expose a hasDepandants (or something similar) to the store so we can know whether or not anybody is using the store.

I believe this will work even for stores calling other stores because nested stores will use the same mechanism to register/unregister the dependant.

So yeah, this are my thoughts. Or maybe there is a cleaner way to achieve the same way in user land that I haven't thought about, I just want to make it as transparent as possible for my developers.

Thank you for your awesome work, you are really pushing the ecosystem with your state management implementation.

[posva]

I'm glad you are enjoying pinia 😄
You can actually call getCurrwntInstance and other hooks within pinia plugins to create that map of stores and handle the way you want

[posva]

That's exactly what I said

[tochoromero]

Gracias, leí tu respuesta mal.

[posva]

Reading this again on a computer.

Note that plugins only run once (v2+) though, but you could wrap the function returned by defineStore() to call something like.

function wrapStore<F extends (...args: any[]) => any>(...args: Parameters<F>): ReturnType<F> {
  const store = originalUseStore(...args)
  if (getCurrentInstance()) {
    onBeforeMount(registerStore(store))
    onBeforeUnmount(unregisterStore(store))
  }
  return store
}

[tochoromero]

Hey @posva, I gave this another try following your latest comment with no luck.
The problem is the onBeforeMount and onBeforeUnmount hooks never get called, I assume it is because the singleton store is created once before any component is mounted.

To be clear I'm calling the wrapStore function instead of calling defineStore when defining my store.

I also tried having a helper composition function I can call from within my stores, and it works great the first time, but subsequent uses of the store does not trigger the hooks, I assume it is because the store is only created once so the hooks are only called once.

Do you have any other ideas, being able to use SWRV is a hard requirement, I would LOVE to use pinia but this is stopping my team to do so :(

Again, I appreciate your help.

[theoephraim]

@tochoromero - did you ever get this figured out? Looking to do something similar with opening/closing websockets while the store is being used. Thanks!

[tochoromero]

Hey, unfortunately no, I was never able to figure it out.

…

On Tue, Sep 6, 2022 at 1:06 PM Theo Ephraim ***@***.***> wrote: @tochoromero <https://github.com/tochoromero> - did you ever get this figured out? Looking to do something similar with opening/closing websockets while the store is being used. Thanks! — Reply to this email directly, view it on GitHub <#669 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAEDP2IN3MK3PNTYJ52TQTV46P4PANCNFSM5D23ZRYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[theoephraim]

@posva @tochoromero - I took a stab at this and got something sort of working.

It works well to track components that use a store directly - meaning they call useStore in their setup function.
The wrapper triggers the lifecycle hooks and we can increment a counter and call some functions if we know we have someone or nobody watching...

The problem is that the composition model of pinia is that stores can use each other directly within getters.

So while this is fine (a store being used directly in a setup function)

const store = useCounterStore();
const count = computed(() => { return store.counter; });

This is not - and is equivalent to what we are doing when we use a store getter that uses another internally

const count = computed(() => {
  // no longer considered within the setup function, cannot call lifecycle hooks here
  const store = useCounterStore();
  return store.counter;
});

This unfortunately triggers a warning and does not work properly. The warning:

Maybe there is a workaround is to require these stores to declare how they use each other rather than relying on the useStore calls within getters. However I'd still need to detect if the useStore call is coming within a setup function or not, and I don't know if that is possible, as it seems getCurrentInstance() returns the instance regardless.

Or we would need a way of dynamically injecting more mount/unmount behaviour into the component outside of the setup function, which I'm not sure is possible?

I do think this kind of functionality could be very useful - and likely should be baked into pinia itself. Would also be useful for initializing watchers and other kinds of behaviour - see this discussion.

@posva - any ideas of workarounds or if it's even possible?

Thanks!!!

---

The code (full working example up here: https://stackblitz.com/edit/vitejs-vite-1czpyx?file=src/CounterWidget.vue)

Plugin:

import { defineStore, PiniaPlugin, PiniaPluginContext } from 'pinia';
import { getCurrentInstance, onBeforeMount, onBeforeUnmount, ref } from 'vue';

declare module 'pinia' {
  export interface DefineStoreOptionsBase<S, Store> {
    // adds our new custom options for activation / deactivation hooks
    onActivated?: (this: Store) => void | Promise<void>;
    onDeactivated?: (this: Store) => void | Promise<void>;
  }
}

export function addStoreHooks<T extends ReturnType<typeof defineStore>>(
  useStoreFn: T
) {
  return (...args: Parameters<T>): ReturnType<T> => {
    // NOTE - was fighting against the TS types in here, but couldn't quite get it right
    // however it's not important to have it working here versus in _consumers_ of the store
    // and it does all work correctly there
    const store = useStoreFn(...(args as any[])) as any;

    const component = getCurrentInstance();

    if (component) {
      onBeforeMount(() => { store.incrementUseCounter();  });
      onBeforeUnmount(() => { store.decrementUseCounter(); });
    }
    return store;
  };
}

export const piniaHooksPlugin: PiniaPlugin = ({
  pinia,
  app,
  store,
  options: storeOptions,
}: PiniaPluginContext) => {
  // might not need this check, but not sure this plugin code is guaranteed to only be called once
  if (store._numStoreUsers) return;

  // attach new counter to track number of components using this store
  store._numStoreUsers = ref(0);
  // expose our new store property in devtools
  if (import.meta.env.DEV) {
    store._customProperties.add('_numStoreUsers');
  }

  store.incrementUseCounter = () => {
    store._numStoreUsers++;
    if (store._numStoreUsers === 1 && storeOptions.onActivated) {
      storeOptions.onActivated.call(store);
    }
  };
  store.decrementUseCounter = () => {
    store._numStoreUsers--;
    if (store._numStoreUsers === 0 && storeOptions.onDeactivated) {
      storeOptions.onDeactivated.call(store);
    }
  };
};

The plugin adds store options onActivated and onDeactivated which use a tracked number of store users to call when the number goes changes from 0 (and back down).

Note that this requires defining the store now looks like:

export const useCounterStore = addStoreHooks(defineStore("counter", {...

This extra requirement is not ideal but is totally reasonable. I had tried to augment defineStore directly but it does not seem possible...

[posva]

It's really up to you if you want to open source this for others to use, I cannot force you to do so but it seems to be useful for some people 😄

This kind of feature is really meant to exist as an external plugin, it shouldn't be added to pinia directly.

About RFCs or feature requests, issues are fine for most cases. Complex ones can go through the RFC process in the vuejs/rfcs repository

[theoephraim]

seems to me like having some way to add some extra initialization logic (like watchers) in option stores would be really nice and useful for many people. Anyway I will get this released soon, but if you change your mind and would accept it in pinia itself, please let me know and I'll open a PR!

Thanks so much @posva! ❤️🍍

[BenceSzalai]

@theoephraim This is a nice plugin, also very educative. Thank you for the effort to share it! Can you please confirm if you consider it MIT or what terms is is usable under?

[BenceSzalai]

looks like I can inject the mount/unmount handlers directly onto the component instance and it works, although this would be using undocumented vue internals and obviously not recommended...

component.bum = component.bum || [];
component.bum.push(() => {
  store.decrementUseCounter();
});

Unfortunately with Vite.js Hot Module Reload onBeforeUnmount() is executed BEFORE onMounted(). (Not sure if intentional or an issue. Suspicious to me...) This code therefore causes the counter to increment by one for every HRM. Indeed it's not an issue in Production, but makes usage in Development mode with HMR misleading.

With

component.um = component.bum || [];
component.um.push(() => {
  store.decrementUseCounter();
});

it works correctly.

Is there a reason you have used onBeforeUnmount() (bum) instead of onUnmounted() (um)?

[BenceSzalai]

@theoephraim I think the issue is because TS gets confused at ReturnType<typeof defineStore>, because defineStore has 3 overloaded definitions, one of which itself is templated. However, if we look at the source of those 3 definitions, we can see that all of them returns a StoreDefinition instance. So this works for me and avoids TS complaints without using any any:

import {PiniaPlugin, PiniaPluginContext, Store, StoreDefinition} from 'pinia';
//...
type StoreWithHooks = Store & {
    trackStoreUsedByComponent: Function;
};
//...
export function addStoreHooks<T extends StoreDefinition>( useStoreFn: T ) {
    return (...args: Parameters<StoreDefinition>): StoreWithHooks => {
        const store = useStoreFn(...args) as UsageTrackedStore;
        const component = getCurrentInstance();
        if (component) store.trackStoreUsedByComponent(component);
        return store;
    };
}
//...

A very similar issue is discussed here on StackOverflow.