Reference type as a default value for a field

[theseyi]

What is the recommended approach when setting a default value that is a reference type on a GraphQLObjectType field
Is this ok?

@ObjectType()
class Identifier {}

@ObjectType()
@InputType('IDInput')
export class ID {
  @Field(() => Identifier)
  id = new Identifier();  <----
}

versus

@ObjectType()
class Identifier {}

const defaultId = new Identifier();

@ObjectType()
@InputType('IDInput')
export class ID {
  @Field(() => Identifier)
  id = defaultId;  <----
}

TypeGraphQL does not seem to like the former, and would just like confirmation since the docs don't seem to prescribe an approach?

[smolinari]

See if your answer isn't in this discussion already.

#498

Scott

[theseyi]

Not quite @smolinari but thanks for your help. I only see this comment
#498 (comment)

Default values for object types are not supported and not tested, so I can't help you with that right now as it's a kinda undocumented feature. I have no idea how defaultValue can work for returned object type as I can't event put that property in ObjectType config of graphql-js.

I assume this is referring to GraphQLObject type not native JS Objects which is what I'm concerned about

[smolinari]

I assume this is referring to GraphQLObject type not native JS Objects which is what I'm concerned about

Let's take a step back. What is the purpose for trying to put a default value on the input object type field? I could assume the purpose, but I'd rather you explain.

Scott

[theseyi]

If no value is provided, I know that it can be done in the resolver as well , but the classes sometimes are used as models outside of graphql so it's better to have them at the source and also in one place. The other reason this was a question is when the schema is rebuilt, TypegraphQL raises an exception for conflicting default values, (even if none is provided in the decorator, this is fixed by 5f864a2). Moving the instance type instantiation outside of the class field resolves this since it is not "newed" on every schema rebuild, hence the question

However, all that being said, seems the bug is in TypeGraphQL as mentioned and confirmed by Michal in his response below. Thanks

[MichalLytek]

@InputType IDInput can't contain a field of @ObjectType type Identifier.
It's against GraphQL spec - there is a difference between object types and input types for some reason 😉
Your schema (types) are invalid no matter what the default values are.
Avoid using double decorators pattern without understarding first all the GraphQL and TypeGraphQL kinks and quirks.

Maybe you wanted to have a reference by using foreign key like xyzId of type number/string?

[theseyi]

I see , can / does TypeGraphQL catch these inconsistencies and raise an exception? Or that's not something that's implemented yet

[MichalLytek]

What inconsistencies are you talking about?

[theseyi]

Raising exceptions where it finds the invalid schema types you mentioned above?

[MichalLytek]

Yes, it will throw an error that unable to find input type of Identifier and you need to decorate it with a proper decorator.

[MichalLytek]

Second things - the default values.
There are two kinds:

• GraphQL default values, which are designed to be displayed in the schema, so they should be constant (not generated uuid or current date)
• runtime default values, when you want to have a new instance of the object (or current date) assigned to the input instance property.

Unfortunately, until #793 is resolved, dynamic default property initializers are used also as the GraphQL schema default values.
So you can't do something like on your snippet, you need to assign new values in your resolvers manually.

[theseyi]

The 2nd kind is partly why I raised the question in the first place. However ,it seems that if the schema is not rebuilt, which seems to be the recommended approach to using TypeGraphQL, then the issue that #793 resolves does not quite present itself.
5f864a2 resolves it otherwise