MichalLytek / MichalLytek/type-graphql
New nullable mode, disallow null for input field but allow undefined
- Dominant language
- TypeScript
- Stars
- 8.1k
- Forks
- 672
- PR merge metrics
- No merged PRs in 30d
Description
**Is your feature request related to a problem? Please describe.**
I'm trying to create a Mutation that allows partially patching an entity which has required fields. Example entity:
```TypeScript
export class Entity {
name: string
description?: string | null
}
```
My current input type for this entity is
```TypeScript
@InputType()
export class EntityUpdateInput {
@Field(() => String, {nullable: true})
name?: string | null
@Field(() => String, {nullable: true})
description?: string | null
}
```
Taking the `description` field as an example, mutations can either
1. Pass a string -> it gets updated
2. Pass null -> the field gets cleared
3. Do no include the field in the argument -> the field is left alone
Now this all works marvelously for an optional field. However, for the `name` field it should not be allowed to pass null as the field is not allowed to be cleared.
**Describe the solution you'd like**
I would like the `nullable` property of the `@Field` decorator to feature an option `optionalOnly` which would result either a) an error being thrown on `null` or b) `null` properties being deleted. This would result in the following input type:
```TypeScript
@InputType()
export class EntityUpdateInput {
@Field(() => String, {nullable: 'optionalOnly'})
name?: string
@Field(() => String, {nullable: true})
description?: string | null
}
```
I understand GraphQL cannot distinguish between nullability (`null`) and optionality (`undefined`) in its generated spec/documentation and that this has the potential of confusing the consumers of an API that differentiates between the two. However, I believe that this use case is a valid one.
**Describe alternatives you've considered**
I've looked into the possibility of using custom validators and `class-validator` to accomplish this but have not found a way so far as I'm not really trying to validate a value but rather, change it.
I had a look at the code of `type-graphql` but have not been able to estimate the time required or impact on the code base of this feature.
**Additional context**
Potentially related to #340 (transforming input fields).
Contributor guide
Research direction
Start by reviewing the @Field decorator's nullable handling and the schema generation paths in type-graphql, then compare the related input-field transformation discussion in #340. Done means establishing whether an optionalOnly mode can be supported and defining the resulting null behavior for input fields without breaking GraphQL schema expectations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, typescript
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100