does optimistic result merge with real results if real results is partial and some q #1793
-
hi , i am learning graph cache and having some trouble here... :( TLDR:
i am trying to do cache update when todo is edited , server only returns statusCode, so i tried to update getTodos cache manually if optimistic result can merge with real results then things becomes easy , because status code would just merge the only solution i can think of other then optimistic updates is to use inspectFields and updateQuery to update all todo list queries if status code is good, else do nothing. i can construct the edited todo item with args. is there a way to directly modify cache without updateQuery , i feel like i can just modify one cache item not multiples queries that has reference with that item ... still no sure how normalized cache works , with updateQuery i don't feel like interacting with a normalized cache at all but with non normalized cache,, and i just update all queries , not one copy of cache , could be totally wrong here . and can optimistic results be permanently, a lot of times, i just need to know of api request failed or succeed, if succeed i don't need to discard the optimistic results tks ! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Updates happen automatically when the entity in question is in the cache this because we can see __typeName:id as an identification and update the fields returned in the mutation response. Addition is the only case where you need to worry about inspectfields and deletion can be done with invalidate. An optimistic result should return the selectionSet your mutation is expecting this means that if your mutation expects id text and __typename that you should return those. The optimistic result is a 'fake server response' and will use the logic in your updaters to layer itself on top of the existing data. So everything untouched by the (optimistic) mutation will have the same data. |
Beta Was this translation helpful? Give feedback.
Updates happen automatically when the entity in question is in the cache this because we can see __typeName:id as an identification and update the fields returned in the mutation response. Addition is the only case where you need to worry about inspectfields and deletion can be done with invalidate.
An optimistic result should return the selectionSet your mutation is expecting this means that if your mutation expects id text and __typename that you should return those. The optimistic result is a 'fake server response' and will use the logic in your updaters to layer itself on top of the existing data. So everything untouched by the (optimistic) mutation will have the same data.