Optional query params

[Allen_Wong]

I am using UDG and resolving a graph by Rest API with connectionArgs

query MyQuery($connectionArgs: ConnectionArgs) {
  notifications(connectionArgs: $connectionArgs) {
    meta {
      count
    }
    result {
      id
    }
  }
}

resolves by http://localhost:3000/listing?start=&limit=
start & limit is optional params, but they should not handle null value

Expected:
when I pass empty connectionArgs, it should resolves by
http://localhost:3000/listing?start=&limit=

Actual:
it resolved by
http://localhost:3000/listing?start=null&limit=null

          "config": {
            "url": "http://localhost:3000/listing",
            "method": "GET",
            "query": [
              { "name": "start", "value": "{{.arguments.connectionArgs.start}}"},
              { "name": "limit", "value": "{{.arguments.connectionArgs.limit}}"}
            ],
            "headers": {}
          }

is there any way I can check if .arguments.connectionArgs is set, else fallback to empty string or default value instead of null? e.g. {{.arguments.connectionArgs.limit || 0}}

Also if the client didnt put connectionArgs as input, UDG cannot resolves the start & limit, but we cannot control how client construct their query, which it should be valid in common Graphql world

query MyQuery($start: Int, $limit: Int) {
  notifications(connectionArgs: { start: $start, limit: $limit }) {
    meta {
      count
    }
    result {
      id
    }
  }
}

[Olu]

@Allen_Wong

is there any way I can check if .arguments.connectionArgs is set, else fallback to empty string or default value instead of null? e.g. {{.arguments.connectionArgs.limit || 0}}

Let me ask internally if this is possible. In the meantime, you could validate or insert a default value with the help of custom plugins. The Pre (Request) middleware section would be a good place for this. You do have to take note that since this is Graphql, the variables are within the body of the request and not the query params.

@Allen_Wong

Also if the client didnt put connectionArgs as input, UDG cannot resolves the start & limit, but we cannot control how client construct their query, which it should be valid in common Graphql world

I will also pose this question internally.

[Olu]

@Allen_Wong How did you get along using custom plugins?

I have got feedback internally

@Allen_Wong

Also if the client didnt put connectionArgs as input, UDG cannot resolves the start & limit, but we cannot control how client construct their query, which it should be valid in common Graphql world

The problem with this approach is, that the input types are defined as nullable which means that if they are omitted they will be treated in the library as null .
So the easiest thing is to have 2 distinct root fields:

{
  notifications(...) { ... }
  allNotifications { ... }
}

with allNotifications having the data source defined without query parameters. This is covered in the spec for input coercion. The spec distinguishes between explicit null and omitted, so that they could be treated differently but the library handles both as null

@Allen_Wong

is there any way I can check if .arguments.connectionArgs is set, else fallback to empty string or default value instead of null? e.g. {{.arguments.connectionArgs.limit || 0}}

No, but we do like the idea of default values. I could open a feature request for this, however, decision to implement the said feature still rests with the engineering team.