GraphQL query typing

[raffazizzi]

Types are currently automatically generated from graphql queries. This is very helpful, but it also creates types with properties that are more often than not nullable. This makes for awkward coding and makes it challenging to extend types. What can we do to make this more useful?

Nullable types

It makes sense for the properties to be nullable because they could be null even though we know from the airtable data that this won't be the case for the vast majority of the fields getting indexed.

Here are a couple possible options:

• Investigate if it's possible to tighten the GraphQL schema so that fields are more predictable and so that errors can be returned on indexing the data if it doesn't match the expected data type.
• Edit the generated types to better match the expected data. We shouldn't modify the AirTable bases and columns often, if at all, so this isn't too bad; but changes, however rare, will need to be introduced manually to the types.
• Possibly a combination of the two solutions above.

Extending types

Currently the main reason for extending types is reconciling data across multiple fields/columns. For example information about event speakers (in column A) and speaker's affiliations (in column B).

Extending types is bothersome for a few reasons:

• the types are deeply nested and typically nullable, which makes for very awkward extensions.
• some subtypes are seemingly repeated but slightly different depending on the query, for example some images include the filepath others don't etc. This is because queries are tailored to their use in the component, which is the right thing to do. This can't really be optimized without moving away from automatically generated types IMO.
• it's verbose and really clogs the code. But they can be moved to a separate file.

It would seem smart to try and prevent the need for extending types at the source, that is, in the AirTable data model. For example, it should be possible to get the speaker data already containing its affiliation, but which affiliation should be shown depends on the event, which complicates things. Perhaps we can review approaches with @ssapienza

[raffazizzi]

ReadOnly types

All types are readonly by default as well. This makes it awkward to make adjustments to the query results, like filtering, deduping, sorting. While it makes sense to not modify the data, typing is still necessary for derived data structures (e.g the result of map, filter, or reduce. It's possible to create mutable versions of the types, but it seems that the extra code / effort brings little advantage in this case?

[ssapienza]

Admittedly I think I'm having trouble understanding the starting point of this issue. By 'types,' do you mean the 16 records in the Types table in the Airtable base (Sponsored Project, Event, Workshop, etc)?