feat: add getInfiniteKey to mutate the cache for useSWRInfinite

[koba04]

fixes #1156

This PR adds a new API called mutateInfinite, which is a mutation function for useSWRInfinite and based on #1156 (comment).

This PR adds a new API called getInfiniteKey to get a key to mutate cache data for useSWRInfinite, which receives a key loader function and returns the key for the cache data.

I feel this is still in discussion and have not meet an agreement, so this is just a POC.

[codesandbox-ci]

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 ef31a87:

Sandbox	Source
SWR-Basic	Configuration
SWR-States	Configuration
SWR-Infinite	Configuration
SWR-SSR	Configuration

[shuding]

Love this. I got another question, how can we have the global mutate function when we are using the cache provider?

[huozhi]

not sure if we want to expose the internalMutate here since createCache has already covered the similar usage

[koba04]

Yeah, I think it's not the best way to support the use case. We might have to find out another solution like exporting a function that returns a key like INFINITE_PREFIX + getFirstPageKey(getKey) rather than exporting a mutate funciton.

[huozhi]

users have the keyLoader definition, at the same time they also have the createCache to get the mutate function, then combining both of them can also achieve the similar approach?

[koba04]

Do you mean like mutate(getInfiniteKey(getKey), 'local-mutation', false)?

[huozhi]

yes, that would be nice!

[koba04]

@shuding

how can we have the global mutate function when we are using the cache provider?

That concern makes sense.
Currently, the global mutate function seems not to work correctly with a custom cache. Is it correct?

I've added mutateCustomCache as a mutate function that works with a custom cache for mutateInfinite 7424dcc.
mutateInfinite works correctly with a custom cache by using the mutateCustomCache efb1459.

But I feel this is not the best way for the feature.
Before working this, should we fix the issue how the global mutate function deals with a custom cache?

Another solution is #1257 (comment)

[koba04]

I've updated this PR to add getInfiniteKey rather than mutateInfinite, which is based on the @huozhi's comment.

Implementing getInfiniteKey is simpler than mutateInfinite and is able to support a custom cache 👍

[shuding]

Thank you! I think this is the best choice for now until we have a better way to work around custom cache providers.

[koba04]

Thank you!🚀

[nicholaschiang]

@shuding @koba04 have you added this API to the documentation yet? If not, could you?

[nicholaschiang]

@shuding could you please release this?

[shuding]

@nicholaschiang A new beta released is there, please check! We will document new APIs when it's stable.

[nicholaschiang]

@shuding this doesn't seem to support mutating based on current data. It's not included in your tests and it's not working here:

// I have an updated message and I need to mutate the list of messages.
const message = { ...prev, subject: 'This is an updated value.' };
await mutate(
  getInfiniteKey(getKey), 
  (data?: MessagesRes[]) => data?.map((messages: MessageRes) => {
    // `data` is always `undefined` even when I know the list has loaded.
    const idx = messages.findIndex((m) => m.id === message.id);
    if (idx < 0) return messages;
    return [...messages.slice(0, idx), message, ...messages.slice(idx + 1)];
  }), 
  false
);

[koba04]

@nicholaschiang I've made a PR to confirm your case.
#1319
This seems to work well in the test case.