Ah ok, so it looks like it is ignoring the old request responses, kind of makes sense.
What I meant with the frequency: If you never would have stopped clicking the "New Quote" button the Quote would never have updated. Even though newer data would have arrived already. I hope this is more understandable.
The good thing about this behavior: it does not look like it is randomly updating the quote after mutate is called multiple times.
This would be not ideal if the API responses are very slow and mutate/update would happen very frequently. Which to be honest is not a very realistic use case.
In this case I would not worry about cancelling the requests, it just makes things more complicated and has no big advantage.
If you want to cut down on requests eg. when typing in a TextBox or to let people hammer that button, you could also use throttle or debounce for the api calls.
For the random quote, disabling the button while fetching is a good solution.
And one thing for your code that just came to my mind: If the code for extracting the quote from data is moved to inside the fetcher logic you have all API related code in one place.
And I would rather use { ...restSWR, quote } than { quote, ...restSWR } because the later always wins over the previous. And as ´quote´ is your own property you would never want that to be overriden by restSWR. (This would only happen if useSWR adds a property called quote though.)
I just updated the article to make the section clearer.
I'm not agree with you that "In this case I would not worry about cancelling the requests, it just makes things more complicated and has no big advantage."
If the user's network connection is slow, It results in a long loading process. If we cancel the unnecessary requests, the last request completes faster. You can check the updated section for more information.
Thanks for your suggestions.
I think, I can move the fetcher function inside the useRandomQuote hook. It seems more appropriate for me.
I will also update the return statement based on your suggestion.
You are right, it can make a difference, especially if the responses are quite big. This would be a nice feature for useSWR
I found that there is a RFC for cancellation with useSWR: github.com/vercel/swr/discussions/... and it has a pull request as well but not reviewed/merged yet.
Ah ok, so it looks like it is ignoring the old request responses, kind of makes sense.
What I meant with the frequency: If you never would have stopped clicking the "New Quote" button the Quote would never have updated. Even though newer data would have arrived already. I hope this is more understandable.
The good thing about this behavior: it does not look like it is randomly updating the quote after mutate is called multiple times.
This would be not ideal if the API responses are very slow and mutate/update would happen very frequently. Which to be honest is not a very realistic use case.
In this case I would not worry about cancelling the requests, it just makes things more complicated and has no big advantage.
If you want to cut down on requests eg. when typing in a TextBox or to let people hammer that button, you could also use throttle or debounce for the api calls.
For the random quote, disabling the button while fetching is a good solution.
And one thing for your code that just came to my mind: If the code for extracting the quote from data is moved to inside the fetcher logic you have all API related code in one place.
And I would rather use
{ ...restSWR, quote }than{ quote, ...restSWR }because the later always wins over the previous. And as ´quote´ is your own property you would never want that to be overriden by restSWR. (This would only happen if useSWR adds a property called quote though.)I just updated the article to make the section clearer.
I'm not agree with you that "In this case I would not worry about cancelling the requests, it just makes things more complicated and has no big advantage."
If the user's network connection is slow, It results in a long loading process. If we cancel the unnecessary requests, the last request completes faster. You can check the updated section for more information.
Thanks for your suggestions.
I think, I can move the fetcher function inside the useRandomQuote hook. It seems more appropriate for me.
I will also update the return statement based on your suggestion.
You are right, it can make a difference, especially if the responses are quite big. This would be a nice feature for
useSWRI found that there is a RFC for cancellation with useSWR: github.com/vercel/swr/discussions/... and it has a pull request as well but not reviewed/merged yet.
Maybe it arrives soon.
I agree that it would be a nice addition to useSWR. I hope the pull request gets reviewed and merged soon.
I appreciate our discussion and your contributions to the topic. If you have any further questions or thoughts, feel free to share them.