-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interaction of mutate & initialData appears to be incorrect #308
Comments
It appears some time ago the `initialData` configuration was used as a fallback. When vercel#211 was merged, this behavior changed to be used with SSR like in the next.js example in the README. Issue vercel#230 explains this was the expectation. I'm using SSR, so im fine with the new behavior. Since `initialData` is now not quickly revalidated, another issue (vercel#308) has been raised. Since `initialData` is not cached, and the mutate w/ callback grabs the curerent data from the cache, when `initialData` is used, `undefined` is returned. fixes vercel#308
@aj-may |
Yea, this is a bit of an annoying bug. I'm working around it for now by immediately calling mutate to fill the cache. Not a great long term solution.
Hope my PR is reviewed and merged soon. I don't see any reason why the |
It seems like a very basic and common behavior. I hope they will fix it very soon. |
It appears some time ago the `initialData` configuration was used as a fallback. When vercel#211 was merged, this behavior changed to be used with SSR like in the next.js example in the README. Issue vercel#230 explains this was the expectation. I'm using SSR, so im fine with the new behavior. Since `initialData` is now not quickly revalidated, another issue (vercel#308) has been raised. Since `initialData` is not cached, and the mutate w/ callback grabs the curerent data from the cache, when `initialData` is used, `undefined` is returned. fixes vercel#308
It appears some time ago the `initialData` configuration was used as a fallback. When vercel#211 was merged, this behavior changed to be used with SSR like in the next.js example in the README. Issue vercel#230 explains this was the expectation. I'm using SSR, so im fine with the new behavior. Since `initialData` is now not quickly revalidated, another issue (vercel#308) has been raised. Since `initialData` is not cached, and the mutate w/ callback grabs the curerent data from the cache, when `initialData` is used, `undefined` is returned. fixes vercel#308
@aj-may |
Yeah, I'm having this bug too. I use SWR to do live edits, where the first time it makes sense to revalidate is when the user saves to the db, not during the edits themselves. Thanks @oran1248 for the workaround. |
I found another workaround, if you're only referencing the SWR key in one place: const {data: rawData} = useSWR('/key', {initialData});
const [data, mutate] = useState(rawData);
useEffect(() => mutate(rawData), [rawData]);
// data + mutate() work roughly as you'd expect |
Is there any movement on this issue? |
I face the same issue when mutate with fallbackData at new version. |
As the new option name |
Hi folks! Lovely module here. Ran into a bit of an issue.
If you use initialData in your initial call to useSWR,
And then someone calls
mutate
with a callback function on the page, then themutate
callback gets undefined as its input, not theinitialData
value. Mutate pulls data from the cache, but initialData is not set in the cache.The end result is that if someone clicks a button that triggers a callback-based mutation before the initial data is revalidated, then the page likely crashes, because you just set the data to
undefined
.Unfortunately, its not easy to work around this issue: I'd be okay with delaying the UI's appearance until there's an item in the cache, but the cache is internal. If I hid the UI based on isValidating, then it would blip whenever there are mutations. The mutate callback can't choose to return
undefined
for 'no effect'.Ideally, mutate would be able to mutate the data in initialData, but I am probably missing something in the philosophy of swr that makes that incorrect.
The text was updated successfully, but these errors were encountered: