More robust handling of local state default value when read function is defined#12934
More robust handling of local state default value when read function is defined#12934jerelmiller merged 26 commits intorelease-4.1from
Conversation
🦋 Changeset detectedLatest commit: 4bceff8 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
size-limit report 📦
|
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: 7e3a261fa5d255f518c30676 |
| }); | ||
|
|
||
| expect(merge).toHaveBeenCalledTimes(1); | ||
| expect(merge).toHaveBeenCalledWith(undefined, null, expect.anything()); |
There was a problem hiding this comment.
If a merge function is present, we'll call it with null as the incoming value which I think makes sense since its resolved from LocalState. When a read function is the only thing defined, the merge function won't be called at all because the incoming value is set to undefined instead and merge functions aren't called in this case.
|
@phryneas would love your initial input on this as a potential solution for the issue. I'll open this up and get ready for merge if you like the approach. |
| @@ -0,0 +1,7 @@ | |||
| --- | |||
| "@apollo/client": minor | |||
There was a problem hiding this comment.
I marked this as minor (in which case we'll want to repoint the branch) since it feels like enough of a change to justify a minor. Happy to update to patch though if it feels more like a bug fix. Opinions welcome.
| @@ -0,0 +1,7 @@ | |||
| --- | |||
| "@apollo/client": minor | |||
There was a problem hiding this comment.
Same. Would like opinions on whether this should be viewed as a minor or patch.
.changeset/shaggy-islands-yell.md
Outdated
| "@apollo/client": patch | ||
| --- | ||
|
|
||
| Warn when using a `no-cache` fetch policy when a `@client` field resolves the value from the cache that defines a `read` function. |
There was a problem hiding this comment.
Can you phrase this differently? Without context, this one might be very difficult to understand.
There was a problem hiding this comment.
Yeesh this was horrible 😅. Updated in 0ff610d
| "The '%s' field resolves the value from the cache, for example from a 'read' function, but a 'no-cache' fetch policy was used. The field value has been set to `null`. Either define a local resolver or use a fetch policy that uses the cache to ensure the field is resolved correctly.", | ||
| resolverName | ||
| ); | ||
| return null; |
There was a problem hiding this comment.
Do we want to return null here even in the returnPartialData: true case?
There was a problem hiding this comment.
I initially thought yet, but I've changed my mind only because there is no other way to resolve the field value. no-cache and returnPartialData are technically incompatible together since no-cache queries don't read from the cache, so there isn't a possibility of a partial result. The same applies here since the value can only be resolved in LocalState when a no-cache query is issued since the read function isn't called. In this case, I think its better to have a null to ensure the query is complete since it can't be resolved any other way.
| } | ||
|
|
||
| // assume the cache will handle returning the correct value | ||
| returnPartialData = true; |
There was a problem hiding this comment.
Changing this here will disable the warning and null-returning behaviour a few lines down for all future fields. Do we want that to happen?
Might be necessary to create an immutable copy of the initial returnPartialData otherwise.
There was a problem hiding this comment.
Discussed in person. This is caught by the conditional below that returns early when the value is null or undefined.
700836e to
01e239b
Compare
57c43dd to
846783f
Compare
Closes #12930.
Better detect whether the cache can handle resolving a client field and warn if neither a local resolver or read function is defined. If a
readfunction is defined, don't set a default value ofnullfor the field to allow for thereadfunction to set the value. This allows default parameters to work again.This also adds a check for
no-cachefetch policies and will warn if used with a@clientfield since the cache is not read. This fixes an issue where using ano-cachefetch policy would read from the cache to get the cachediffto resolve the field.