Use persist with already existing storage.

[jmysliv]

Recently I was adding zustand to a project that was previously persisting state manually. One of the requirements was not to lose data that was already persisted in the storage. The problem was that persist expects the persisted state to have the following format:

const storageValue = {
    state: {
        count: 1,
    }
}

If it's different, i.ex. like this:

const storageValue = {
    count: 1,
}

then undefined is returned. I found that it's not currently possible to handle that case without losing data that is already stored in the storage. To overcome this I created a patch that adds one more option to persist - a callback that is called when storageValue.state is undefined. It allows users to define how to parse the already persisted value. Is that something that perhaps should be added to zustand? If so, I can create a pull request with the necessary changes.

Here's the diff with the changes I made: main...jmysliv:zustand:@jmysliv/get-state-fallback

[dai-shi]

To me, this feels beyond the scope of persist design.
Having that said, if we can implement it with fairly a small change, it might be acceptable.
I wonder if we can tweak the migrate option instead of introducing a new option.

[jmysliv]

I wonder if we can tweak the migrate option instead of introducing a new option.

I think that it might introduce breaking changes. migrate is called with deserializedStorageValue.state, to support the case I described it should be called with deserializedStorageValue, which will be a breaking change. Also migrate is called only when the version is specified in the storage value, and in the described case version might not be specified. So I think tweaking migrate option might introduce too many changes (possibly breaking) and it would be better to introduce a new option. I think it's fairly small change, 45 added lines.

[dai-shi]

Unfortunately, it feels too big.
I think it's the design decision. I've been already a bit skeptical about migrate even, because it's not often used, and I also previously recommended using custom storage for more control such as migrating from different storage format. So, I think it's fairly reasonable to say that your case is out of the scope of persist in this repository. That doesn't block someone to develop a more featured persist library in the ecosystem.

[jmysliv]

Okay, thanks for your response!