Issue implementing custom cache in 1.0.0-beta.9

[beetlebum]

I have implemented a custom cache following the examples in the documentation.

Given that the methods in the Cache interface take a string as a parameter, get: (key: string) for example, I assumed that the keys were being serialised before being passed into these methods.

I am seeing array keys coming through into the cache keys, causing all sorts of issues.
Also, the serialize key method is not exported as far as I can tell.
It seems like function type keys are being converted to strings before arriving at the cache.

Am I missing something or is this a bug?
Should I stop using arrays as keys in the new version?

Thanks in advance.

[huozhi]

Nice call @beetlebum , yet it's not an ideal solution to expose the serialization helper gracefully but we're working on it.
it could be either exposing the method directly or we give another parameter like raw keys to arrive cache along with string key and value.

[shuding]

I am seeing array keys coming through into the cache keys, causing all sorts of issues. Also, the serialize key method is not exported as far as I can tell.

May I ask what exactly the issues are? As a cache backend usually it doesn't need to be aware about the original cache keys (string or array of strings), it just need to provide a KV-like functionality. I'm curious about your scenario here, to improve the API we need to understand those use cases better. Thanks!

It seems like function type keys are being converted to strings before arriving at the cache.

This is expected. The function itself isn't a key type for SWR, that function argument is used for returning an actual key.

[beetlebum]

I am seeing array keys coming through into the cache keys, causing all sorts of issues. Also, the serialize key method is not exported as far as I can tell.

May I ask what exactly the issues are? As a cache backend usually it doesn't need to be aware about the original cache keys (string or array of strings), it just need to provide a KV-like functionality. I'm curious about your scenario here, to improve the API we need to understand those use cases better. Thanks!

It seems like function type keys are being converted to strings before arriving at the cache.

This is expected. The function itself isn't a key type for SWR, that function argument is used for returning an actual key.

Thanks for your message.

I'm probably missing something but let me explain what I'm trying to do.

In the provider I will see keys serialised, like:

 LOG  {"key": "key_activity_summary_api"}
 LOG  {"key": "$err$key_activity_summary_api"}
 LOG  {"key": "$req$key_activity_summary_api"}

When I need to access a cached item, if available, previously I would use the exposed cache.get(key) method, but now I'm trying to access the provider directly and I only have the original key, not the serialised one, so this is not possible.

I use the cache.get() version to populate initialData in some cases, like for example I might have a cached version of an item from a collection endpoint, and want to display as initial data it while I load the whole item.

For reference, I'm working with React Native, and trying to implement a disk backed custom cache using MMKV.

[shuding]

With v1, we've updated the cache API interface, and added a new API to help you serialize keys:

import { unstable_serialize } from 'swr'

unstable_serialize(key)

We might polish that API in the future, as we are thinking about supporting more options here.