feat(batch-delegate): added mapping function to createBatchDelegateFn

[jakeblaxon]

TODO:

• If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

I love the recent addition of the batch-delegate package! The only thing that prevents me from using it is the inability to edit the server's response before returning the results to the dataloader. I believe there is a general need for this feature (e.g. what if the array of entities is not in order, or what if the we want to group entities together by key for a one-to-many relation?), so I wrote a quick PR to make this available. Let me know what you think!

[yaacovCR]

Thanks for your work on this! You can modify the result prior to it's conversion to a proxied result (in which the data is extracted and annotated with errors) by passing an additional transform with a transformResult property, but I agree that it makes sense to provide a direct option.

See additional comments in the review. Thanks again!

[yaacovCR]

What do you mean by:

what if the we want to group entities together by key for a one-to-many relation

Sounds interesting!

[yaacovCR]

We could definitely change arguments to named properties within option object, preserving backwards compatibility to original order....

[jakeblaxon]

That's a use case that I've encountered before. Let's say you have an authors and a books schema. To stitch them, you can add an author.books field that's of type Book[]. The resolver for this field could definitely benefit from a batch delegate function, passing in multiple author ids as the keys to get multiple books. The problem, though, is that there's no way to currently manipulate the response to group books together by author id, since there could be many books per author. This is one use case that the resultsFn could solve, looking something like:
resultsFn = (results, keys) => keys.map(key => groupBy(results, "authorId").get(key));

[jakeblaxon]

I'll leave it up to you how you handle the arguments. If we're not expecting the list of arguments to grow often then it's probably ok as it is. Either way we can always change it in a future PR/new release version.

[yaacovCR]

I have been thinking this over and wondering whether overall the workflow should be changed to eliminate the need for the createBatchDelegateFn step and just do everything in one go as.a batchDelegate function that uses whatever arguments are passed to it similar to delegateToSchema with addition of key, argsFn, resultsFn, and adjustment of returnType.

I think that is the direction I am heading in, but I think absolutely no harm in merging this PR in the meantime anyway.

[theguild-bot]

The latest changes of this PR are available as alpha in npm: 6.0.16-alpha-cb7385ff.0

Quickly update your package.json by running:

npx match-version @graphql-tools 6.0.16-alpha-cb7385ff.0