-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider narrowing the strings allowed for condition records in ConditionExpressionJSON #230
Comments
Someone recommended using Zod, which supports static typing of object schemas: #94 It would solve the ambiguity of keys here, and the ambiguity of types in a bunch of other places. |
Could be interesting. We probably would need to push out any possible changes to Zod to a post-7.0.0 release. Also, it remains to be seen what ripple effects moving condition code to Generally, I think this specification: type ConditionProps = 'operator' | 'method' | 'contractAddress';
export type ConditionExpressionJSON = {
version: string;
condition: Record<ConditionProps, unknown>;
}; should not try to specify type ConditionRecord = TimeConditionRecord | RPCConditionRecord | ContractConditionRecord | ...
export type ConditionExpressionJSON = {
version: string;
condition: ConditionRecord
}; That way you can be a lot more specific, and reuse the schema information from the various conditions themselves, instead of trying to define something separate. In any case, this is not meant to be a comment on Zod, but rather a comment on what that expression should really be doing. |
Because of type ambiguity, the resulting
I agree that issue could be reviewed post-7.0.0 and after reviewing possible changes to |
Closed via #267. |
See conversation from PR review here - #229 (comment).
Maybe we can use the schema fields defined for underlying conditions to limit the record keys that can be used with
ConditionExpressionJSON
object.The text was updated successfully, but these errors were encountered: