refactor(populate): fields-based populate #2897
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #1149
Summary
This changes the way we populate slightly, rather than going over queries and assembling fragments for all the fields we find, we iterate over all selections within queries and hold a graph of all the requested fields. When we see a mutation we look at the return-type and start filling out the selection-sets based on the observed fields.
The issue now becomes that this keeps growing, we could say that when a
teardown
happens that we remove the fields but then we run the risk that data in the cache remains stale as a torn down query does not mean we remove the cached data so mutations on data that isn't mounted would become stale.Proposal: we introduce a max-depth of for instance 3 so it only fills out that much in the selection sets, most commonly in mutations the first-level already reflects most things needed.
Todo:
Future pull requests: