-
-
Notifications
You must be signed in to change notification settings - Fork 670
Description
Is your feature request related to a problem? Please describe.
When declaring optional properties on an input object, it would be nice if the @Arg decorator respected the default vaults provided in the @InputType.
I have an example reproduction here: https://github.com/dwjohnston/type-graphql/tree/master/examples/defaulting
Say I have an object representing a list of filters.
All of the filters are optional from the consumers point of view, but if not provided, some kind of default will be used.
@InputType()
export class RecipeFilterInput {
@Field(() => [RecipeTags], {
// The property is nullable
nullable: true,
defaultValue: [RecipeTags.Vegan],
})
// But is typed to always exist, because the default value will be provided.
allowedTags!: RecipeTags[];
}
When we go to use this as an arg:
We also want the filters object itself to be nullable. If the user does not provide the object, then we would want one of the filter objects will all the default values to be used.
There's a few ways this can be done, I'll list them here.
Approach 1 - nullable, no default value provided. ❌
async recipes(
@Arg("filters", {
nullable: true,
})
filters: RecipeFilterInput,
): Promise<Recipe[]> {
console.log(filters);
This will error when executing:
query ExampleQuery {
recipe {
title
}
}
With:
"message": "Cannot read properties of undefined (reading 'allowedTags')",
(filters logs undefined).
This also errors when executing
query ExampleQuery($filters: RecipeFilterInput) {
recipes(filters: $filters) {
title
}
}
input: {
"filters": null
}
"message": "Cannot read properties of null (reading 'allowedTags')",
Approach 2 - nullable, with an empty object default value provided. ❌
async recipes(
@Arg("filters", {
nullable: true,
defaultValue: {},
})
filters: RecipeFilterInput,
): Promise<Recipe[]> {
console.log(filters);
This doesn't error, but it doesn't have the desired behaviour when we execute this query:
query ExampleQuery {
recipe {
title
}
}
(filters logs RecipeFilterInput {}).
Approach 3 - nullable, with full defaulting provided: ✅ ❌
async recipes(
@Arg("filters", {
nullable: true,
defaultValue: {
allowedTags: [RecipeTags.Vegan],
},
})
filters: RecipeFilterInput,
): Promise<Recipe[]> {
console.log(filters);
This works, for a query like this:
query ExampleQuery {
recipe {
title
}
}
But not for a query like
query ExampleQuery($filters: RecipeFilterInput) {
recipes(filters: $filters) {
title
}
}
input: {
"filters": null
}
This approach is also not ideal, as it has us repeating the defaulting logic in two places.
Describe the solution you'd like
What should happen in this scenario is two parts.
-
The framework asserts for the existence of the arg object. If it does not exist, provide the default value. (Empty object in approach 2, Full object in approach 3).
-
Then, the framework inspects the properties of the object, if they do not exist, it provides the default value as defined in the
@Fieldannotation.
Describe alternatives you've considered
A partial alternative is that we don't provide a single object for the filter, and instead we provide the filters individually:
async recipes(
@Arg("allowedTags", () => [RecipeTags], {
nullable: true,
defaultValue: [RecipeTags.Vegan],
})
allowedTags: RecipeTags[],
): Promise<Recipe[]> {
console.log(allowedTags);
This solves the redundancy of providing the default values in two places. But It will still have non-defaulting behaviour if the user does provide a null argument.
Alternative solution is to abandon any defaulting logic via type-grapqhl and just do something like:
async recipes(
@Arg("filters", {
nullable: true,
})
filters: RecipeFilterInput | null,
): Promise<Recipe[]> {
console.log(filters);
const filterSet = new Set(filters?.allowedTags ?? [RecipeTags.Vegan]);
Additional context
Related issue: