Replies: 1 comment 1 reply
-
Hi! This sounds like a bug because even if SWR does key serialization now, it still sends the original key object (not the serialized one) to fetcher. It would be great if you can share some example of the keys - maybe there’s a bug in key serialization?
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
v 1.1.2
Hi!
Currently, we can supply our own
compare
function in theuseSWR
options(or global options) to compare the new and old results to each other. Would it be possible/advisable to add a key serialization function as well?Rationale
In previous versions, when the keys were not deeply serialized and instead shallowly compared, we could get away with sending complex objects (that NEVER change internally) in the key array and have them delivered to the fetcher. In our case, it was an API imported from autogenerated code that we needed to use in the fetcher. But since the change to serialization, that whole thing broke(SWR got into some kind of infinite reloading loop).
It would be great if we could either serialize the key ourselves or perform some action on it before SWR serializes it, while still maintaining the key array as-is when sending its contents to the fetcher function. I had a quick look at the middleware docs about serialization, but that would not work (I am assuming) since the fetcher function would still end up with the serialized key instead of the original.
I hope this makes sense.
Beta Was this translation helpful? Give feedback.
All reactions