Make keyArgs tolerant of optional arguments. #7109
Conversation
The keyArgs:[...] configuration for field policies should be able to include arguments that are optional, while still specifying an ordering of all possible key arguments for serialization purposes. When an optional argument is not provided, it will simply not be included in the serialized storeKeyName suffix, and no exception will be thrown. Should address #6973.
| if (hasOwn.call(response, responseName)) { | ||
| keyObj[prevKey = s] = response[responseName]; | ||
| } else { | ||
| invariant(!strict, `Missing field '${responseName}' while computing key fields`); |
There was a problem hiding this comment.
We use this computeKeyObject helper function for both keyArgs and keyFields, but because strict is always false in the keyArgs case, we never throw an exception here, which is good because "while computing key fields" was a poor error message for a problem with keyArgs.
| } | ||
| } else { | ||
| const aliases = aliasMap && aliasMap.aliases; | ||
| const responseName = aliases && aliases[s] || s; | ||
| invariant( | ||
| hasOwn.call(response, responseName), | ||
| // TODO Make this appropriate for keyArgs as well |
|
I still have the issue in 3.3 with optional arguments not specified by the query, I still get the error: Uncaught Invariant Violation: Missing field 'activeOn' while computing key fields Were activeOn is specified in the typePolicy keyArgs but not specified and occuring in the query . |
|
@robertsmit Are you absolutely sure you're working with |
Currently no problems any more... maybe I did used keyFIelds instead of keyArgs... |
As suggested by @tadhglewis in #6973.
The
keyArgs: ["someArg", "anotherArg"]configuration for field policies should be able to include arguments that are optional, while still specifying an ordering of all possible key arguments for serialization purposes.When an optional argument is not provided, it will simply not be included in the serialized
storeFieldNamesuffix, and no exception will be thrown.We cannot safely do the same thing for
keyFields: [...]in type policies, since a consistent set of primary key fields (for a given__typename) is required to (re)identify objects over time.