Question: TypeGraphQL uses functions to prevent circular dependencies-wouldn't this package's API suffer from the same problem?

[capaj]

the quote from:
https://19majkel94.github.io/type-graphql/docs/types-and-fields.html

Why function syntax, not simple { type: Rate } config object? Because this way we solve problems with circular dependencies (e.g. Post <--> User), so it was adopted as a convention. You can use the shorthand syntax @Field(() => Rate) if you want to safe some keystrokes but it might be less readable for others.

[MichalLytek]

https://github.com/prismake/typegql/blob/6797a9ad0e0449e569e8f7c247d0ddc4c2c16f65/docs/explore/object-type-and-field.md#circular-type-references

[capaj]

cool, but wait do you contribute here too @19majkel94 ?

[MichalLytek]

@capaj Nope, I just secretly watch all related projects and sometimes try to help in the name of the open source community 😉

[capaj]

@19majkel94 nice 🥇 I have to say It's a shame you don't work on the same project with @pie6k, because you two would make a great team-both of your libraries have very similar API and design goals. Seems like a waste of time to be working separately. But I guess in such an early stage of graphQL ecosystem more POCs isn't such a bad thing.

[MichalLytek]

@capaj
I've proposed that a long time ago:
indigotech/graphql-schema-decorator#65 (comment)

But since that time our visions have splited - this is what @pie6k said:

So I think it's better when users have an ability to choose between library vs. framework and also the competition makes the development faster 😄

[capaj]

@19majkel94 great to hear what the difference really is. I can certainly appreciate both approaches-I am sure there are going to be apps well suited to both paradigms. Thanks for all the info! I am considering using one or the other in our API at Looop.co and these are exactly the things I need to know.

[pie6k]

Thanks @capaj @19majkel94 .

Right, if you've got circular dependencies you'd have to use type lazy function like:

import { ObjectType, Field } from 'typegql';

@ObjectType()
class Car {
  @Field({ type: () => Person })
  owner() {
    return db.findPersonByCarId(this.id);
  }
  @Field() id: number;
}

@ObjectType()
class Person {
  @Field() id: number;
  @Field() name: string;
  @Field({ type: () => Car })
  car() {
    return db.findCarByOwnerId(this.id);
  }
}

Note it might be not needed anymore if typescript itself would make reflection metadata lazy in its core.