-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically filter out dangling references from arrays. #6454
Conversation
This commit implements the proposal for automatic filtering of dangling references that I described in #6425 (comment). The filtering functionality demonstrated by #6412 (and updated by #6425) seems useful enough that we might as well make it the default behavior for any array-valued field consumed by a selection set. Note: the presence of field.selectionSet implies the author of the query expects the elements to be objects (or references) rather than scalar values. By making .filter(canRead) automatic, we free developers from having to worry about manually removing any references after evicting entities from the cache. Instead, those dangling references will simply (appear to) disappear from cache results, which is almost always the desired behavior. In case this automatic filtering is not desired, a custom read function can be used to override the filtering, since read functions run before this filtering happens. This commit includes tests demonstrating several options for replacing/filtering dangling references in non-default ways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🦆 🐂 🐔
if (field.selectionSet) { | ||
array = array.filter(context.store.canRead); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that executeSubSelectedArray
is result-cached (like executeSelectionSet
), so this filtering only happens when we're recomputing the current result object.
Also note that the original array remains unfiltered in the cache. I described a possible strategy for permanently pruning the list in #6412 (comment), though I don't think that should be necessary in most cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great @benjamn - thanks!
This commit implements the proposal for automatic filtering of dangling references that I described in #6425 (comment).
The filtering functionality demonstrated by #6412 (and updated by #6425) seems useful enough that we might as well make it the default behavior for any array-valued field consumed by a selection set. Note: the presence of
field.selectionSet
implies the author of the query expects the elements to be objects (or references) rather than scalar values. A list of scalar values should not be filtered, since it cannot contain dangling references.By making
.filter(canRead)
automatic, we free developers from having to worry about manually removing references from lists after evicting entities from the cache. Instead, those dangling references will simply (appear to) disappear from cache results, which is almost always the desired behavior. Fields whose values hold single (non-list) dangling references cannot be easily filtered in the same way, but you can always write a customread
function for the field, and it's somewhat more likely that a refetch will fix those fields correctly.In case the automatic list filtering is not desired, a custom
read
function can be used to override the filtering, sinceread
functions run before this filtering happens. This commit includes tests demonstrating several options for replacing/filtering dangling references in non-default ways.