Skip to content

refactor(graphql): deliver various manuscript properties using sub-resolvers

Ben Whitmore requested to merge refactor-resolvers-20230424 into main

To date, each resolver that returns a manuscript object or objects has had to gather and groom a whole load of complex data: adding related items such as teams, tasks, channels, reviews etc; replacing images in source html with time-limited URIs; redacting confidential information from reviews, etc. This has several drawbacks:

  • It complicates the code a lot.
  • There are inconsistencies, with some resolvers skipping some of these tasks depending on what we assume the result will be used for.
  • It's inefficient: often the client just needs some of these items, not all. But we're gathering them regardless.
  • It's forcing poor design choices on other resolvers. Example: updateTasks resolver should ideally return a manuscript object, so that its updated task array can be retrieved: then the cache update on the client would be automatic. But because we don't want the updateTasks resolver to have to do all the data grooming required for a manuscript, it instead returns an array of tasks, and we have to write complex code on the client to manually update the cache.
  • It's not how graphql is supposed to be used.
  • It makes testing harder.

To solve this, I have shifted responsibility for all specialised manuscript properties into separate resolvers. So for instance there's a separate resolver for manuscript.meta, and another for manuscript.meta.source that replaces all files in the html with appropriate URIs.

There are still some resolvers that could be further simplified as a result of this.

Merge request reports