This PR adds support for an optional --leafsPath command line argument. If provided, the leafs file should contain a JSON object with GraphQL types (including unions, if desired) as keys and "leaf" fields to include as as array values. For example:
When gql-generator encounters the listed types anywhere other than at the top-level, it will exclude any fields not included in the associated array.
We implemented this because we use a lot of nested revolvers, and the queries, while useful, were also large and unwieldy. This feature allows us to still generate comprehensive queries, without the redundant overkill of traversing Types that have their own stand-alone queries.
I implemented this feature for my team's internal use. If this doesn't seem generally useful to others, feel free to close this PR.
I've updated the PR to make it more flexible. It now takes a generic filter function that takes in a number of variables. This solution is more imperative, but it allows greater latitude for potential use cases.
Hi!
This PR adds support for an optional
--leafsPath
command line argument. If provided, theleafs
file should contain a JSON object with GraphQL types (including unions, if desired) as keys and "leaf" fields to include as as array values. For example:When
gql-generator
encounters the listed types anywhere other than at the top-level, it will exclude any fields not included in the associated array.We implemented this because we use a lot of nested revolvers, and the queries, while useful, were also large and unwieldy. This feature allows us to still generate comprehensive queries, without the redundant overkill of traversing Types that have their own stand-alone queries.
I implemented this feature for my team's internal use. If this doesn't seem generally useful to others, feel free to close this PR.