how to get a "hash" of the validator?
for TanStack Start server functions, I try to find out whether a input validator changed from one deployment to another. Is there a way in arktype (or ideally in standard schema) to get a hash or stringified version of the whole validator that I can use for that?
28 Replies
.expression in ArkType is TS syntax representation of the type that will get you most of the way there but wouldn't include all metadata
The property you really want is called hash, but I don't expose it by default. You can access it with myType.internal.hash.
However, if your schema includes non-serializable conditions, it could change from one build to the next even if the schema itself didn't changeand I suppose there is nothing in the standard about this either?
No. I do see the utility but it's quite a big ask, I doubt valibot would be able to implement something like that without a significant impact on bundle size
At best it would be an optional prop
optional would be better than nothing 😄
is there any way I could build this myself through some AST traversal?
or stringifying a TS type?
In ArkType or what?
for example yes
.internal.hash is exactly what you are looking foroh
nice
What I mentioned about non-serializable conditions is true inherently
what does the hash look like?
Looks like a stringified version of the normalized JSON representation of the type
cool
If you think about e.g. if you have an anonymous predicate like
foo.narrow(() => true), all we can do is generate an id for that like $ark.anonymousFn1 that we store in memory. However, that is not guaranteed to be stable because if e.g. another function is referenced somewhere unrelated, that might end up as anonymousFn2 and the hash would change
Maybe an important aspect of the problem more broadly, but not something that you could create a robust workaround for if you had to try and detect that caseso we could detect changes but not detect whether it is stable
You could always reliably for detect changes for anything serializable.
Exceptions to that would be e.g. symbols, custom narrowing or transform functions,
=== someObject etc.
But for any of those things, you could get false negatives, and technically even false positives although the circumstances around that would be very convolutedcustom functions could be stringifed though ?
You could try to use the function's stringified representation but there's no way to make it robust because you can't encode its scope
ok so I might not be looking for a hash of the validator
but more of the types
input and output
so the goal is to provide skew protection for server functions.
If you had rules about functions needing to be pure etc. you could cover more cases that way potentially but that is also messy of course
if the input type changed, a newly deployed version of the backend is not compatible with the old client
A validator (custom predicate) is considered part of the input type in ArkType though
Only transformations are not part of an input/output
yeah I would not care about transforms
as long as the client input would be accepted
What is an example of a function like this and how it would change
If I can see the exact scope of what you're trying to capture change in and how it fits into the broader project I might be able to give better guarantees
see this https://tanstack.com/start/latest/docs/framework/react/server-functions#using-a-validation-library
Server Functions | TanStack Start React Docs
What are Server Functions? Server functions allow you to specify logic that can be invoked almost anywhere (even the client), but run only on the server. In fact, they are not so different from an API...
if the required shape of
Person changed, it would not be compatible anymoreWhat about a change like this though:
Before:
I think the problem is these questions are not possible to answer in a general sense
right
so maybe the signal really is just "if the input validator fails, it might be cause of version skew"
thanks for discussing this with me, it definitely helped to clear my naivety here 😉
Haha I'm glad it was helpful. Definitely the kind of thing you don't think about until you're trying to precompile arbitrary value references and it becomes painfully clear how messy it all is ðŸ«