Type/Data runtime validation on state change

[overthemike]

I had a thought of maybe adding a chainable "schema" function that could be defined before the proxy call that would allow for using something like zod to validate the values as they are changed and revert back to a previous state and/or throw an error if failed.

Here's a idea of what I mean:

    import { z } from 'zod';
    import { schema, proxy } from 'valtio'

    const UserSchema = z.object({
        name: z.string(),
        email: z.string().email()
    })
    
    const state = schema(UserSchema).proxy({
        name: 'John Doe',
        email: 'email@email.com' 
    })
    
    state.name = 5 // 'John Doe' - won't update from previous state because it fails validation

I'm thinking the schema function could return a Proxy that will have have set traps to test the input before passing it on to the state proxy to do the rest of it's magic.

I haven't really thought through this too deeply so I'm not sure if it's really even feasible. Many heads are better than one.

[overthemike]

Just now found this: #297. Didn't look like it got much traction, though the implementation never seemed to get thought through. I'm wondering if there's really even a need to modify how proxy() works at all and maybe just put a new different proxy that handles this sort of thing as a layer in front of proxy that will or won't pass the values to be updated. This way it wouldn't be a big change for how proxy works and it can be optional simply by not using it.

[dai-shi]

Yeah, double proxy should work and easier.

If we want a single proxy solution, it's a little bit difficult. For now, what's exposed is unstable_buildProxyFunction but it can be too low level. I would like to revisit it.

Anyway, validation is out of the scope of the Valtio core, and I would highly encourage anyone to create a wrapper library. If you are interested, I can invite you to https://github.com/valtiojs. We can start with double proxy solution. Like proxyWithValidation.

[dai-shi]

Oops, on second thought, double proxy doesn't work because of proxyStateMap, if the validator proxy is outside of valtio proxy. Valtio proxy being outside might work, but might have a pitfall.

[overthemike]

Yeah an invite would be great. Would love to contribute where I can.

Hm - would referential equality even be an issue if we create the proxy within the trap and just pass it along if validation passes and throw an error if it doesn't? We don't have to modify the proxy at all, just basically create a guard in front of it.

[overthemike]

Oh wait nvm. I think I see what you mean. We would need to modify the proxy in order to create the set trap on value updates. Duh. Hmm - I'm gonna think on this for a bit and come back with some ideas.

[overthemike]

Thinking out loud here...what if this kept it's own track of the structure of whatever state is passed in, creates the proxy for that state and stores the proxy(ies) as well so that when a property is mutated, it will validate the value based on it's own structure first, and if it passed, it then does the same mutation on the proxy object. Downside is that we would essentially be duplicating the store's structure (though not the state). Does that make sense?

[overthemike]

So I looked into this a bit more in depth and have come to the conclusion that trying to implement generic validation that's not specific to a library might not be the best way to do this. Each library has their own rules and parsing methods and valtio's proxy methodology might work with some without issues with some libraries and might require extra code for others. I think it would either be overly-complicated to both use and maintain if we tried to implement generic work arounds for everything instead of just creating a different wrapper library for different validation libraries. I would probably prioritize Yup and Zod first as I believe they are probably the most widely used ones and then maybe a version that allows users to create their own custom validation logic. I actually have already started experimenting with something that I think would fit really well for that last one. I'd be happy to try and get things started once you send me an invite and we can probably move this discussion over there.

[dai-shi]

sounds good.