Migrating from pinia-plugin-persistedstate-2

[Stanzilla]

Describe the bug

I'm currently migrating my app from pinia-plugin-persistedstate-2 to this version since it is no longer maintained. I use it inside of an Electron app and have ipc functions mapped to store methods:

async function getStore(key) {
  return await ipcRenderer.invoke("getStore", key);
}

async function setStore(key, value) {
  return await ipcRenderer.invoke("setStore", key, value);
}

async function deleteStore(key) {
  return await ipcRenderer.invoke("deleteStore", key);
}

(async () => {
  const app = createApp(App);
  const pinia = createPinia();

  pinia.use(
    createPersistedState({
      storage: {
        getItem: async (key) => {
          return getStore(key);
        },
        setItem: async (key, value) => {
          return setStore(key, value);
        },
        removeItem: async (key) => {
          return deleteStore(key);
        },
      },
    }),
  );

and it complains that

  Type 'Promise<any>' is not assignable to type 'string'.ts(2322)

Is that what is mentioned on https://prazdevs.github.io/pinia-plugin-persistedstate/guide/limitations.html?

Reproduction

import { ipcRenderer } from "electron"; import FloatingVue from "floating-vue"; import { createPinia } from "pinia"; import { createPersistedState } from "pinia-plugin-persistedstate"; import { createApp } from "vue"; import App from "./App.vue"; import { i18n } from "./libs/i18n"; import "virtual:uno.css";  async function getStore(key) {   return await ipcRenderer.invoke("getStore", key); }  async function setStore(key, value) {   return await ipcRenderer.invoke("setStore", key, value); }  async function deleteStore(key) {   return await ipcRenderer.invoke("deleteStore", key); }  (async () => {   const app = createApp(App);   const pinia = createPinia();    pinia.use(     createPersistedState({       storage: {         getItem: async (key) => {           return getStore(key);         },         setItem: async (key, value) => {           return setStore(key, value);         },         removeItem: async (key) => {           return deleteStore(key);         },       },     }),   );    app.use(pinia);   app.use(i18n);    app.use(FloatingVue, {     themes: {       "info-tooltip": {         $extend: "tooltip",       },     },   });    app.mount("#app").$nextTick(() => {     postMessage({ payload: "removeLoading" }, "*");   }); })();

System Info

"pinia-plugin-persistedstate": "^3.2.1",#    "pinia": "^2.1.7",

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible of the bug.

[prazdevs]

The plugin only supports synchronous storages to match pinia's mutation system. This is indeed one of the limitation.

[Stanzilla]

The plugin only supports synchronous storages to match pinia's mutation system. This is indeed one of the limitation.

Can you suggest a migration path for users coming from the abandoned -2 version then?

[prazdevs]

Well I didnt make the -2.

This plugin has only ever officially supported synchronous storages as mentioned in several issues (#17 #111 #214).
You can use pinia actions for this, or the hooks, or still use non-awaited functions in the storage, but may experience side effects.

[Stanzilla]

Well I didnt make the -2.

This plugin has only ever officially supported synchronous storages as mentioned in several issues (#17 #111 #214). You can use pinia actions for this, or the hooks, or still use non-awaited functions in the storage, but may experience side effects.

Oh yeah, I'm aware, I was just wondering if you have a suggestion for a replacement path, I'll look at actions but that looked like I have to have those defined for every store instead of globally, thanks!

[Stanzilla]

Well I didnt make the -2.
This plugin has only ever officially supported synchronous storages as mentioned in several issues (#17 #111 #214). You can use pinia actions for this, or the hooks, or still use non-awaited functions in the storage, but may experience side effects.

Oh yeah, I'm aware, I was just wondering if you have a suggestion for a replacement path, I'll look at actions but that looked like I have to have those defined for every store instead of globally, thanks!

Would be cool if you could do something like this:

pinia.use(
    createPersistedState({
      actions: {
        getItem: async (key) => {
          return getStore(key);
        },
        setItem: async (key, value) => {
          return setStore(key, value);
        },
        removeItem: async (key) => {
          return deleteStore(key);
        },
      },
    }),
  );

[prazdevs]

Due to the way the plugin behaves and how pinia handles it, synchronozing data from async sources is out of the scope of the plugin. My advice would be to have calls done on app startup then calling stores to update the data. That would be the safest way without risking race conditions having async calls in sync functions.

Closing this 😌