Stream payload "data" field

[robrichard]

Context

Raised by @IvanGoncharov:

Currently, our spec proposal defines a single payload object used for incremental delivery, with the properties data, errors, label, path, & hasNext.

For @defer payloads, data will always be an object or null type.

For @stream payloads. data will always be an array or null type (decided in #32).

Should we instead define two discrete payload types, and modify the @stream payload to use a different field name (e.g. items) instead of data? This could potentially allow better static typing of the payload shapes.

Decision

Based on below discussion, stream payload will use items instead of data.

[mjmahone]

I basically always will prefer differently-behaving things having different names, so my preference is data: {...} and items: [...] although data is already plural so it technically matches both cases :)

[leebyron]

I lightly agree with this.

Does this help with the path discussion at all?

[michaelstaib]

@mjmahone I also thought about data already being plural. Its a bit odd but it solve the issues where we cannot really distinguish where data is a list or an object . So I am on favor of data: {...} and items: [...].

[hwillson]

data: {...} and items: [...] sounds great to me (and several other folks I've chatted with). 👍

[maraisr]

What do you do when both is defined? Or let the spec read they MUST not be be defined, and always take preference if data?

[robrichard]

Seems like there is general agreement on renaming to items. I am going to move forward with this approach.

Both the spec PR and graphql-js PR have been updated to reflect this.