[Data masking] Core data masking algorithm #11686
Conversation
|
|
Just out of interest - is there a reason you're not hooking into that as part of the cache, about here? apollo-client/src/cache/inmemory/readFromStore.ts Lines 442 to 453 in 1dfd5aa |
jerelmiller
changed the title
| >( | ||
| data: TData, | ||
| document: TypedDocumentNode<TData> | DocumentNode, | ||
| matchesFragment: MatchesFragmentFn |
There was a problem hiding this comment.
I think this name could be changed. This is really only used to check against a type condition on an inline fragment to see if we should dig into its selection set. Perhaps name this something like matchesTypeCondition, matchesInlineFragment, or matchesInlineFragmentCondition?
src/core/masking.ts
Outdated
| return [memo, true]; | ||
| } | ||
| }, | ||
| [Object.create(Object.getPrototypeOf(data)), false] |
There was a problem hiding this comment.
any particular reason we can't at least stay with null here? :)
There was a problem hiding this comment.
Mostly because I was trying to make the replacement object as much like the original, including its prototype. I suppose we could use null directly since we know we create objects with null prototypes, but does it hurt to leave this?
There was a problem hiding this comment.
Only if we want to count bytes 🤷
| user { | ||
| __typename | ||
| id | ||
| fullName: name |
There was a problem hiding this comment.
Maybe also add a test that shows that a fragment/inline fragment inside an aliased field is also honored correctly.
src/core/__tests__/masking.test.ts
Outdated
| }, | ||
| ]; | ||
| const drink = { __typename: "Espresso" }; | ||
| const originalData = { user, post, authors, industries, drink }; |
There was a problem hiding this comment.
Maybe also deep-freeze this to show it's not modified?
There was a problem hiding this comment.
Good call! Added in 7a33acf
Co-authored-by: Lenz Weber-Tronic <lorenz.weber-tronic@apollographql.com>
Part of #11671
Adds the core algorithm for removing fragments from queries. This work only includes the mechanism to strip out fragments from queries themselves, but does not use this anywhere or include any kind of registry to store the data. This work also does not include any kind of caching against the work. These changes will be done in a future PR.
Here I'm looking for feedback on the initial implementation to look for optimizations or holes in the solution that haven't been accounted for.