What happens to atomWithStorage items when removed? Can you migrate?

[GollyJer]

I'm eager to try out jotai but curious about persisted data changes.

What happens when I remove an atomWithStorage atom from the code, or rename one? Is the persisted data stuck on disk?

Am I missing some way to migrate persisted data?

Am I stuck in a flux mindset and need to change the way I'm thinking this?

Thanks!

[dai-shi]

There's no magic behind atomWithStorage. If you remove it from the code, the data will be kept in localStorage.
For migration, you would need to provide a custom storage. We don't yet have a detailed doc about it. Basically, you need to implement a SyncStorage, if you are using localStorage.

type SyncStorage<Value> = {
  getItem: (key: string) => Value
  setItem: (key: string, newValue: Value) => void
}

[dai-shi]

I might have misunderstood what you mean by migration.

both,
easy-peasy -> zustand
easy-peasy - > jotai
should be fine.

No need to go,
easy-peasy -> zustand -> jotai

[GollyJer]

Your original interpretation is correct. This will be a rewrite from easy-peasy to jotai.

I'm focused on the functionality I don't want to lose which is the ability to migrate the local data when we change it's structure.

Here's an exact example we often do...
Our users have a list of addresses (in the store) and all the other data is queried and organized based of these addresses.
Often we update how the other data is structured but don't want to lose the addresses.
To do this we "wipe" all the state except the addresses.

const migrations = {
  0: (state) => ({ addresses: { ...state.addresses } })
  1: (state) => ({ addresses: { ...state.addresses } }),
}

const persistConfig = {
  storage: ExpoFileSystemStorage,
  version: 1, // Change this to match the migration number.
  migrate: createMigrate(migrations),
};

After a migration the app pulls down all the data for each address and puts the results in the new structure.
Without this ability our users would need to re-enter their addresses; we don't want to make them do this.

I think you've answered how I can change the storage to persist for React Native but I'm missing how a migration like this might work.

Thank you for taking the time to help!!

[GollyJer]

Should I be looking at valtio instead of jotai?
Seems like it might be even better.

Sorry, I'm trying to get up to speed on all these amazing new ways of managing state.

[dai-shi]

The normal atomWithStorage usage in RN would be:

import { atomWithStorage, createJSONStorage } from 'jotai/utils'

const storage = createJSONStorage(() => AsyncStorage)
const fooAtom = atomWithStorage('foo', null, storage)

Let's suppose you have a migrate function that you can call even if it's already the latest format.
You could do something like this:

import { atomWithStorage, createJSONStorage } from 'jotai/utils'

const baseStorage = createJSONStorage(() => AsyncStorage)
const storage: typeof baseStorage = {
  ...baseStorage,
  getItem: async (key) => {
    const value = await baseStorage.getItem(key)
    return migrate(value)
  },
}
const fooAtom = atomWithStorage('foo', null, storage)

[dai-shi]

Should I be looking at valtio instead of jotai?

valtio is close to zustand in that it's module states.
jotai is modeled after useContext+useState.
If you need to read store values outside React, valtio and zustand would be easier.