Valtio with persisted state

[GollyJer]

OK, I put about 20 hours into playing with and understanding Valtio over the last few days. Here's a little story and then a codesandbox with what I've come up with. Hopefully it helps others. Or @dai-shi can tell me I'm doing it wrong. 😀

We have a React Native app, token.art NFT viewer, that makes extensive use of "computed" state and persistence. Our current state package isn't being maintained and has some bugs. It is time to make the switch.

Here are the requirements.

• Supports Typescript types. Ideally written in Typescript.
• Rehydration and data migrations can happen before <App> is rendered.
• A persistence package is available. ✅ Thanks @Noitidart. 🎉
• State slices can be persisted separately.
• State files can logically contain state & actions in one file.
• We can structure files so everything is super easy to consume in app; ideally one export file (stretch goal).

This codesandbox shows what I came up with.

The key insight came when reading the wiki. Specifically, How to Organize Actions. It gave me the inspiration to separate the exports. State is a default export and actions are grouped together in a single named export.

This allowed the passing of only the state object to valtio-persist...

...and re-importing the persisted state proxy back into the "state" file for use in actions.
See (import { state } from "./"; in thing.ts above).

Then a nested folder structure with a well placed index file that re-exports all the named exports...

... leads to persisted and reactive state that is easy to access from the top level "store" import.

And last but not least... types are correctly inferred and used for auto-complete and visible on hover.

Now adding a new piece of persisted state is as simple as creating a new file in the state folder, adding the default import to persist, and reexporting the actions at the store level.
🎉

Here's the codesandbox again. Playing with it will help.

I'm very curious to hear anyone's opinions.
For now this is the approach I'm going to use in our app. 👍

[dai-shi]

Nicely done.
I don't think you need to export thing1 and re-import from parent. (if I understand how proxyWithPersist works correctly.)
Please git it a try.

const thing1 = proxy(INITIAL_STATE)
const add = () => { thing1.number += 1 }
export default thing1
export const thing1Actions = { add }

[dai-shi]

looks clean

[GollyJer]

It turns out that this approach (the original topic of this discussion) doesn't work, at all, with react-native and async storage. 😭

[Noitidart]

Oh no, why is that? I'm using it successfully with Expo. What part is not working?

[GollyJer]

I'll hit you up in your github about the issues. My app is also built with Expo. A major issue I ran into was using an array in the proxy.

Also had to make my own storage to get it working and had to make a lot of changes to persist so I pulled in your raw code and started hacking away.

Let's definitely collaborate on making a great valtio-persist package.
Finishing up an app release today and then I'll post in your issues. 👍

[Noitidart]

Oh thank you! Oh an array use case that's very interesting. I think valtio-persist should definitely support that. I'll work on something right now.

[Noitidart]

Thanks for the call out and trying out the lib. Way appreciate it!

State slices can be persisted separately.

That was a big one for me too, so I included that in the lib. :)

I do have to add error handling, like when a file read fails it should log or something. redux-persist was also silent about errors, so I didn't prioritize this in v1.

[GollyJer]

Yeah man. We have one object that is huge (and not written often) and the rest are pretty small. Re-writing all of them each time was such a drain. redux-persist didn't have this option and stumbling on valtio AND your package that came along with it. Pure gold! Thanks again.

I did have one specific question I wasn't sure about. Might have slipped through the notification cracks. Pretty sure it has to do with serializing via JSON.stringify.
👉 Noitidart/valtio-persist#1

[Noitidart]

Oh shoot so sorry, checking now, missed that notification, thanks!

[Noitidart]

For this image below, I see default export is proxy(initialState). Why is this done? Why not just export the initialState without wrapping it into a proxy?

The one reason I could see on wrapping initialState in proxy in that file, is if you want to make your actions work on that. So you don't have to re-import the persisted state.

So the options I'm thinking of up there are this:

Option 1 - export initial state and re-import persisted state

import { state } './';

export default initialState;

const add = () => {
  state.thing1.number = 1;
}

Option 2 - export proxied initial state, and connect actions to this proxy. no re-import of persisted state

I'm not sure if this actually works. But the idea here is to not re-import persisted state. Changes on this proxy will make the persisted proxy persist it.

const thing1 = proxy(initialState);

const add = () => {
  thing1.number = 1;
}

export default thing1;

and persisted:

import thing1 from './thing1';

const state = proxyWithPersist({
  initialState: {
    thing1
  },
  ...
});

[Noitidart]

oh please ignore, i think thats what daishi is mentioning above. and you mentioned reseting state was causing issue.

[GollyJer]

Thanks for the response. We're all on the same page. An ideal solution allows confidently resetting state without the need to reimport and do the object spread. We're working through a solution in the comments of Daishi's answer. 👍