PageInfo type field nullability different from specification

[Cito]

The relay spec says that "PageInfo must contain fields hasPreviousPage and hasNextPage, both of which return non‐null booleans. It must also contain fields startCursor and endCursor, both of which return non‐null opaque strings."

However, the Flow type for PageInfo makes all of them nullable, and the GraphQL object type for PageInfo makes startCursor and endCursor nullable.

Can we fix these types to conform to the specification?

[Cito]

This should also solve #240.

[olso]

Just ran into this

I'm doing this until its fixed

[numberten]

Even though the spec claims startCursor and endCursor must be non-null, I believe they need to support null to handle where the edges return an empty list.

[GabrielGil]

Indeed. I have run into the same incongruence, and it is not clear what option is correct. Either the spec is just ambiguous or out of date, or maybe this library is just taking a different approach.

Either way, in case the spec is respected, and both startCursor and endCursor are not null opaque strings, what should be their value when there are no results? Should the connection be null? Should the cursors be an empty string?

[Cito]

It seems this has been (accidentally?) solved by #300 already.

[bamorim]

@Cito thanks for reporting that, just stumbled upon this as I was confused about the spec and some implementations out in the wild.

I seems that #300 still marks the endCursor and startCursor as nullables:

  startCursor: ConnectionCursor | null,
  endCursor: ConnectionCursor | null,

https://github.com/graphql/graphql-relay-js/pull/300/files#diff-c906c9bb7d4a80f721e5ef3e8c7159dda11e5f8829ace2f04982a460a453c0a2R12-R13

It only fixes the nullability of hasPreviousPage and hasNextPage.

[IvanGoncharov]

@Cito Thanks for reporting it spec should definitely be clarified about the values of startCursor and endCursor in case of an empty array.