I appreciate the flexibility type policies bring. In practice, I’m surprised the amount of maintenance we are expected to put into type policies. I want to check if my understanding/setup is correct. If so, offer some suggestions on how Apollo could make things easier.
The main source of field policies in our code base are:
- List/Array fields: since there is no default strategy for array/list fields, we should be setting a strategy for all of them (one can argue some of the fields will never be updated, but that require business logic specific knowledge).
- Pagination: we are using relay, and we need to make sure all our connections are specified with
relayStylePagination(). This unfortunately cannot be done as a type policy, it has to be a field policy, so whenever we are using a connection type field, we need to addrelayStylePagination().
During our 2 → 3 migration, we quickly discovered that it’s very hard to rely on runtime warnings and testings to make sure the policies are set right. We ended up generating a base type policy programmatically with graphql-code-generator. Our strategy is to set all list fields with { merge: false } (correct in our set up), and all connection files with relayStylePagination().
The result file is 230 lines long. While I’m happy that it’s automatically generated. It simply doesn’t seem maintainable, especially manually.
My specific suggestions:
- Allow setting default merge strategy for arrays
- Allow setting
relayStylePagination()on type.keyArgscould be an issue here, which probably should only be support on field level.