future-proof package for migrating persisted zustand stores

[rob-gordon]

I wrote a library for migrating data and I tailored the API to work well with the persist middleware. It's called future-proof.

Here's what a full example looks like with zustand:

import { create } from "zustand";
import { persist } from "zustand/middleware";
import { from } from "future-proof";

type State = { x: number; y: number; z: number; θ: number };
const initialState: State = {
  x: 100,
  y: 100,
  z: 100,
  θ: 0,
};

// We began with x and y properties...

const { version, migrate } = from({
  x: 100,
  y: 100,
})
  .to((data) => ({ ...data, z: 100 })) // Later on, we added z...
  .to((data) => ({ ...data, θ: 0 })) // Even later on we added θ
  .init(initialState);

const useStore = create<State>()(
  persist((set) => initialState, {
    name: "my-persisted-store",
    version, // 👈 version & migrate get passed directly to persist
    migrate,
  })
);

That's it! I use zustand persisted stores in so many projects, which is what inspired me to abstract this into a package. I hope it helps other people as well.

[dohomi]

Hello
I am currently trying to move from localStorage persistence to idb-keyval store. Do you have an idea how to migrate the localstorage data into a different storage? This is how my new (version 2) storage would look like:

export const IdbStorage: StateStorage = {
    getItem: async (name) => {
        // Exit early on server
        if (typeof indexedDB === "undefined") {
            return null;
        }
        const value = await get(name);
        console.log("load indexeddb called");
        return value || null;
    },
    setItem: async (name, value) => {
        // Exit early on server
        if (typeof indexedDB === "undefined") {
            return;
        }
        return set(name, value);
    },
    removeItem: async (name) => {
        // Exit early on server
        if (typeof indexedDB === "undefined") {
            return;
        }
        await del(name);
    }
};

I am not sure if your plugin is actually meant to archive this use case

[rob-gordon]

My plugin is meant for supplying just the migrate and version arguments to the persist middleware. The storage is loaded before migrations are called during hydration, so it's not really how I intended the plugin to be used. That said, if you have a way to access the corresponding localStorage (the localStorage key is fixed and you know it, for instance) then in theory you could assume that changing to idb-keyval storage will return a version of 0 because it's new, and you could provide one migration that grabs the value from local storage and returns it.

import { from } from "future-proof";

const { migrate, version } = from({
  /* ... */
})
  .to((_) => {
    // load local storage and return it here
    const oldData = localStorage.get("KNOWN_KEY");
    if (oldData) return oldData;
    // Default to new version
    return initialStorage;
  })
  .init(initialStorage);

export const useBoundStore = create(
  persist(
    (set, get) => initialStorage,
    {
      name: 'food-storage', // unique name
      storage: createJSONStorage(() => storage),
      version,
      migrate
    }
  )
)

So long story short. Seems like it should work, in theory, but it's not exactly how I intended it to be used.

[dohomi]

Thanks a lot that make sense. I will see how to deal with my current issue.