MichalLytek / MichalLytek/type-graphql

New nullable mode, disallow null for input field but allow undefined

Open
#1,276 2 comments 3 reactions 0 assignees View on GitHub
Community :family_man_girl: Enhancement :new:
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.