allow for "shared component results" using the useMutation hook
#1477
Conversation
|
✔️ Deploy Preview for redux-starter-kit-docs ready! 🔨 Explore the source changes: 4b389bf 🔍 Inspect the deploy log: https://app.netlify.com/sites/redux-starter-kit-docs/deploys/61324996412a8c000764453d 😎 Browse the preview: https://deploy-preview-1477--redux-starter-kit-docs.netlify.app |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 6db0429:
|
size-limit report 📦
|
phryneas
force-pushed
the
v1.7.0-integration
branch
from
844299f to
43bba18
Compare
| const reset = useCallback(() => { | ||
| if (promise) { | ||
| setPromise(undefined) | ||
| } else if (fixedCacheKey) { | ||
| dispatch( | ||
| api.internalActions.removeMutationResult({ | ||
| requestId, | ||
| fixedCacheKey, | ||
| }) | ||
| ) | ||
| } | ||
| }, [dispatch, fixedCacheKey, promise, requestId]) |
There was a problem hiding this comment.
💁
I think this logic makes it so that when using a fixed cache key, the component that calls reset needs to call it twice before it actually removes the result for that key
e.g.
- Components A & B with a shared mutation key
- Component A triggers the mutation
- Component A stores the promise in state
- Components A & B both receive the mutation result
- Component A calls
reset - The promise state in component A is set to undefined, but the mutation result for the cache key is left alone
- Components A & B both still receive the mutation result
- Component A calls
resetagain - The mutation result for the cache key is now removed
My immediate thought is to change the else if (fixedCacheKey) to just if (fixedCacheKey)
There was a problem hiding this comment.
Good catch. My thought was: Setting promise to undefined should trigger the useEffect cleanup further up, which also triggers a reset.
But unfortunately, that skips in that case:
useEffect(
() => () => {
if (!promise?.arg.fixedCacheKey) {
promise?.reset()
}
},
[promise]
)Could you open a PR against the integration branch and maybe also add a test for this to prevent regressions?
This needs docs to be written, but should be ready otherwise.
It would be used like
That cache key would be shared over components and never cleaned up, so the result would stay around until either
result.reset()ortriggerare called (the first removing the result, the second overwriting it with new results).The only caveat: When using
fixedCacheKey,originalArgswill always beundefined. We cannot reliably guarantee that to be there in any situation, since we keep them out of the store (for mutations, they are often non-serialiazable) and we cannot keep them "to the side" as then they would not be able to be restored in a persistence or SSR situation, so we explicitly set them toundefinedas soon asfixedCacheKeyis being used.The persistence problem even exists without
fixedCacheKey, so we should maybe even think about generally deprecating them and encourage people to holdoriginalArgsto the side manually if they need them for something.Installation instructions are in the CodeSandbox build page.