SelectionType is a graphql concept

[rbalicki2]

• When processing the GraphQL schema, we need two steps: first, do the entities, then do the selectables
• That's because we don't know if in user: User, User is scalar or object, and we categorize selectables by whether they're scalar or object selectables
• Instead, we can just have a single "Selectable" struct, and one has to look up what it points to to determine whether it is a scalar or object selectable.
• This simplifies a lot and seems worth it.

[rbalicki2]

Related to #780.

I think the difference between scalars and objects is overrated. e.g. imagine a Date scalar (an ISO string). One can select that as date, which returns the string itself. Or one can select date { formatted }. Or, one can select data { formatted __self } to get both.

Likewise, a User object. One can select that as user, which would be an empty object, and which would translate to user { __typename id }, or user { __self }, which is user: { __self: {} } or user { __self foo }.

So, for any selectable and any entity, it is always valid to select foo foo {} and foo { bar } and foo { __self }

So, IMO, this implies that an entity is not a scalar or object entity! Instead, whether something is a scalar or object entity lives in network_protocol_associated_data, and affects query generation, but not iso literals

[rbalicki2]

The distinction between client and server selectables makes sense, though, because a client selectable is "expanded" at merged selection set creation time.

But IMO it might be best to have a single selection struct which has a field on it associated_data: DefinitionLocation<...>, where the client info consists of selection sets, etc. and the server definition into consists of a pointer to an entity. This field is used to distinguish between server and client selectables.

[rbalicki2]

See #793.

Basically, we should only have entities + scalars + selections (each with an optional nested selection set). There shouldn't be the concept of selection type.

Instead, Entities will have a generic NetworkProtocol::EntityAssociatedData, and likewise for selections, which contains info like "this is a scalar/type/union/etc", which is used when generating the query text, and perhaps when generating the merged selection set (i.e. it might have to influence the normalization AST?)

And selections may also have and need such associated data.