Store created/disposed lifecycle hooks

[bisubus]

What problem is this solving

The suggestion is to provide created and disposed lifecycle hooks in store setup options to access store instance as soon as it's created. Since a store isn't tightly coupled with Vue component lifecycle, there may be no need match it closely.

This would allow to keep code that is relevant to a store together. Currently this requires to scatter store logic across the application and move to a place where a store can be accessed - entry point, root component, a plugin. The latter is less suitable for this because it applies to all stores and needs to be additionally controlled through store options.

It's possible to run code on store instance creation in setup function but it's designed to be low-level. This makes setup options lacking in a features and requires to rewrite them to a function.

For example, subscribe to the same store:

// App.vue
const store = useStore();

store.$subscribe((mutation, state) => {
  localStorage.setItem('store', JSON.stringify(state))
});

Link store A to B changes, with B being unaware of A:

// App.vue
const aStore = useAStore();
const bStore = useBStore();

watch(
  () => bStore.foo,
  foo => {
    aStore.doBar(foo)
  },
  { deep: true }
);

Proposed solution

// aStore.js

const useAStore = defineStore('a', {
  state: ...
  actions: {
    updateBar(foo) {
      // Some side effects
    },
  },
  created() {
    this._unwatchFoo = watch(
      () => bStore.foo,
        foo => aStore.doBar(foo)
      },
      { deep: true }
     );
   },
   disposed() {
      this._unwatchFoo();
   }
);    

Describe alternatives you've considered

In order to avoid scattering store logic across many files and avoid unnecessary maintenance it's possible custom wrappers to access store instance:

const defineMyStore = (id, options) => {
  const useStore = defineStore(id, options);

  let createdStore;

  return (...args) => {
    const store = useStore(...args);

    if (!createdStore) {
      // call options.create, override store.$dispose
      createdStore = true;
    }

    return store;
  };
};

It would be good if the library provided this out of the box without a risk to break a store. $dispose already can be overriden by devtools.

[posva]

This is a good idea for a plugin, similar to https://github.com/posva/pinia-plugin-debounce/.

Given that disposing of stores is an edge case, this is preferred to be added as a plugin to not impact other users.

FYI, setup stores function is the created hook:

defineStore('id', () => {
  // subscribe to stuff here
})

[guswelter]

what's the philosophy lifecycle hooks not being core functionality?

[bisubus]

@posva It actually is, I will likely publish it later, but it also would be good for the lib to back it to make it seamless. The thing I already noticed is that $disponse has to be monkey-patched, which looks like a design flaw. Can we address this?

[katerlouis]

@bisubus what do you mean by "the lib to back it"? Maybe I'm just dumb, but please elaborate 😮‍💨

[emahuni]

https://github.com/posva/pinia-plugin-debounce/

@bisubus Please announce the publish when you do. Thanks.

[bisubus]

@katerlouis In the link above it can be seen that the lib has no mechanism to subscribe to store dispose/destroy and has to patch store.$dispose method to track it in devtools, which is hacky. It would be better if there were dispose event that could be subscribed instead

[dmolesUC]

Are stores ever $dispose()d other than if you call $dispose() explicitly? I can't find any invocations in the Pinia source, but maybe I'm not looking hard enough.

Naively, I would have expected that unsetting or replacing the active Pinia would dispose all stores, but that doesn't appear to be the case — after I monkey-patch $dispose as in the devtools plugin (and for that matter several places in the Pinia source), my monkey-patched version only seems to be called if I call it myself (e.g. in a vitest afterEach()).

[bisubus]

No, it can be seen in the codebase that it's supposed to be called explicitly