Skip to content
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

Closed
EmileSpecs opened this issue Apr 23, 2024 · 4 comments
Closed

Circular references #844

EmileSpecs opened this issue Apr 23, 2024 · 4 comments

Comments

@EmileSpecs
Copy link

EmileSpecs commented Apr 23, 2024

Hi

I've tried to make sense of some of the other issues that have similar problem, but still can't figure it out.

// NOTE: these schemas are defined in different files and are displayed here as is for reference, thus I'm not getting errors like:
// Block-scoped variable 'accountSchema' used before its declaration.ts
const userSchema = Type.Object(
  {
    id: Type.String({ format: 'uuid' }),
    email: Type.String({ format: 'email' }),
    account: Type.Ref(accountSchema)
  },
  { $id: 'User', additionalProperties: false }
)

const accountSchema = Type.Object(
  {
    id: Type.String({ format: 'uuid' }),
    name: Type.String(),
    users: Type.Array(Type.Ref(userSchema)),
    locations: Type.Array(Type.Ref(locationSchema))
  },
  { $id: 'Account', additionalProperties: false }
)

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?

@truumahn
Copy link

truumahn commented Apr 23, 2024

One slightly unrelated thing is that you're using accountSchema before it is initialized, TS throws a clear compilation error on this:

Block-scoped variable 'accountSchema' used before its declaration.ts(2448)

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.

@EmileSpecs
Copy link
Author

Thanks @truumahn for the answer.

The solution however causes more downstream issues in the context I'm using it in.
I've thus also asked my question here:
feathersjs/feathers#3472

As the context is clearly important here.

I don't really see any way around this, as any circular references will need to use Type.Recursive which is not going to work in feathersjs unless there are changes made there.

Feel free to add more if you've got ideas, thanks!

@sinclairzx81
Copy link
Owner

@truumahn

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.

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 examples for future reference.

@EmileSpecs

I don't really see any way around this, as any circular references will need to use Type.Recursive which is not going to work in feathersjs unless there are changes made there.

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 A/B type into feathers and test. Technically speaking, this should work. If you can do this and just let me know how things work out, that would be great (helps provide me a bit more insight into Feathers usage)

Cheers
S

@sinclairzx81
Copy link
Owner

@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.
All the best!
S

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants