-
Notifications
You must be signed in to change notification settings - Fork 170
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
Circular references #844
Comments
One slightly unrelated thing is that you're using
Instead of using the schemas directly I personally created schema builder generic functions that accepts a schema as a parameter, that way you can create recursive types. const userSchemaBuilder = <T extends TSchema>(reference: T) =>
Type.Object({
id: Type.String({ format: "uuid" }),
email: Type.String({ format: "email" }),
account: Type.Optional(reference),
});
const accountSchemaBuilder = <T extends TSchema>(reference: T) =>
Type.Object({
id: Type.String({ format: "uuid" }),
name: Type.String(),
users: Type.Optional(Type.Array(reference)),
});
const userSchema = Type.Recursive((This) =>
userSchemaBuilder(accountSchemaBuilder(This))
);
const accountSchema = Type.Recursive((This) =>
accountSchemaBuilder(userSchemaBuilder(This))
);
type user = Static<typeof userSchema>;
type account = Static<typeof accountSchema>; It's a little bit of a dependency injectionish' pattern, it works both for the types and the schemas and the schemas can be isolated to their own modules this way. I haven't benchmarked it so I don't know what memory or processor impact it has, because technically some schemas are duplicated. What would be nice to figure out is to how to make the builder functions expect a certain schema shape from the parameter, because right now nothing prohibits you from passing any kind of schema. |
Thanks @truumahn for the answer. The solution however causes more downstream issues in the context I'm using it in. As the context is clearly important here. I don't really see any way around this, as any circular references will need to use Feel free to add more if you've got ideas, thanks! |
@truumahn
Your implementation for mutual recursive types is possibly the best representation possible today (and thanks for writing that up!). I've been searching for better patterns but generally blocked by the "order of definition" problem. In terms of overhead, there is a little bit of duplication of the schematics for either entry point, but should be relatively negligible. As for your implementation, it's a really good one and I might include in the
Feathers is on an older version of TypeBox, but the Recursive types should still work (I believe the version they are on have the current implementation of Recursive types). Internally, Feathers is using Ajv for validation, the following is a quick code snippet you can test TypeBox + Ajv in isolation. import { Type, TSchema, Static } from '@sinclair/typebox'
import Ajv from 'ajv'
const __A = <T extends TSchema>(reference: T) => Type.Object({
b: Type.Optional(reference),
}, { additionalProperties: false })
const __B = <T extends TSchema>(reference: T) => Type.Object({
a: Type.Optional(reference),
}, { additionalProperties: false })
// ....
type A = Static<typeof A>;
type B = Static<typeof B>;
const A = Type.Recursive((This) => __A(__B(This)))
const B = Type.Recursive((This) => __B(__A(This)))
const ajv = new Ajv()
console.log(ajv.validate(A, {
b: {
a: {
b: {
a: {
b: {
// optional a
}
}
}
}
}
})) You may be able to rig above Cheers |
@EmileSpecs Heya, Might close off this issue here and track things over at feathersjs/feathers#3473. The above solution provided by @truumahn should be supported in Ajv, so to investigate things further, would likely need to see a repro project using Feathers (as I'm not clear why the mutual type wouldn't work there). I'll be available for comment on feathersjs/feathers#3473 if I can provide assistance there, so feel free to ping me there if I can offer any insights. Will close off for now. |
In case anyone is looking for a way to define circular dependencies between more than two types, here's one way: const makeA = <B extends TSchema, C extends TSchema, D extends TSchema>(b: B, c: C, d: D) =>
Type.Recursive((a) => Type.Object({ a, b, c, d }))
const makeB = <C extends TSchema, D extends TSchema>(c: C, d: D) =>
Type.Recursive((b) => {
const a = makeA(b, c, d)
return Type.Object({ a, b, c, d })
})
const makeC = <D extends TSchema>(d: D) =>
Type.Recursive((c) => {
const b = makeB(c, d)
const a = makeA(b, c, d)
return Type.Object({ a, b, c, d })
})
const makeD = () =>
Type.Recursive((d) => {
const c = makeC(d)
const b = makeB(c, d)
const a = makeA(b, c, d)
return Type.Object({ a, b, c, d })
})
const dSchema = makeD()
const cSchema = makeC(dSchema)
const bSchema = makeB(cSchema, dSchema)
const aSchema = makeA(bSchema, cSchema, dSchema)
type A = Static<typeof aSchema>
type B = Static<typeof bSchema>
type C = Static<typeof cSchema>
type D = Static<typeof dSchema> |
Hi
I've tried to make sense of some of the other issues that have similar problem, but still can't figure it out.
This produces an error for both schemas: "'accountSchema/userSchema' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer."
This is of course because they both reference each other which causes some kind of circular reference issue.
Any advice on how to make this work?
The text was updated successfully, but these errors were encountered: