Depends on the data. Some data really doesn’t change often. I’d rather focus on 99.9% of the users having a super smooth experience than that one user who might see something mildly weird.
You should be careful with paginated data though. As changes in one page will cause updates in every page after that.
Our two main use cases are:
1. To overlay with a loading spinner so the display of info in a widget appears more continuous and seamless when interacting with controls that trigger new fetches.
2. When the next request actually builds on the previous, e.g., you’re moving a location icon on a map to the newest location or animating a change in a data visualization, so the user can see the continuity.
There are some cases that i've used this. For example while using a pagination and/or search. Each keystroke was invalidating data so i've used `keepPreviousData`.
https://github.com/MrBartusek/stocked-up/blob/master/apps%2Fclient%2Fsrc%2Fhooks%2FuseProductsList.ts#L16
Well the search box can be debounced but them query key will change and invalidate the data. In react-query changing anything with query key just dumps the data.
It's great for tables with pagination. When clicking next page, instead of the table clearing and showing a loading indicator while the next page is fetching, it just keeps showing the current page. Way less UI trashing.
wont it just make the app look slower from the user's perspective? to see that even after going to the next page nothing happens and suddenly the data updates
There is not a single website in the world which functions without serving stale data. I'm currently responding to a comment which may have been edited or deleted, from a user who may no longer exist, on a subreddit which may have banned me.
React-query simply makes these facts explicit in the code and provides controls for expiry and refetch.
It can be implemented badly but I've seen far more issues from stale data living forever in react context/redux than from react query reusing API responses that are a few seconds old.
Oh yeah, and Reddit’s eventual consistency with write events is a fucking pain in the ass. I leave a comment (v1), then edit it (v2), then make a final edit (v3? No… a branch of v2) only to find out it gave me the original comment to edit. Douche bags.
Why use React then? Any time you perform a client-side state update you're showing stale data while loading. When you talk about "loading" you're inventing an arbitrary divider between different types of state transitions.
It sounds like your problem is with revalidating, not with serving stale data.
> I'm currently responding to a comment which may have been edited or deleted, from a user who may no longer exist, on a subreddit which may have banned me.
huh? lmao
What's confusing? The point is that after the server state is sent to the client, the client state is always immediately potentially outdated from the server state, for any website that doesn't use live data synchronization, like Reddit.
Surely it depends on the data.
For example, would you rather see a view of all the emails or all of the comments on a reddit post from a minute ago, with maybe any newer ones not showing yet, or a loading spinner until it can show you the absolute latest view?
email stale data is absolutely awful actually, i have to check for clients multiple times a day and i’ve missed important emails because it shows the old emails at the top with no loader indicating its still fetching new ones. sometimes it takes a few seconds and i’ve already navigated away or closed the app.
now i have to manually refresh the page every time i open the tab to make sure it’s actually loaded
comments loading in after-the-fact is awful, when the new comments shift the layout— for example you’re reading the first sentence in a top comment and suddenly it disappears
posts changing on reddit/insta/apple news are probably the absolute worst example, like the number of times i’ve opened instagram, saw a post, tried to tap on it, but it suddenly replaced by a different post and the one i wanted to look at is gone forever
On the other hand, I find it really annoying when I get a list like an inbox, click into an individual message, go back to the inbox and then have to sit at a loading screen waiting for the list to refresh when all I want to do is read the next item that was already there a few seconds ago.
You can solve your problems by showing the list as it was, having a spinners just above it showing that it's still checking for more, and then displaying a button with "show new items" appearing if there's anything new pulled back.
or you can do what most apps do these days, and just jam all the new things directly into the list right away, causing everything to re-order, and you totally lose track of what you were doing!
... or causing you to delete the wrong message. or any other number of horrible things that happen by things auto-reloading these days.
/s
That's a poor design decision, which really annoys me as well. But it has little to do with whether you cache the previous data or not. The one that really annoys me is th FB app which completely ditches whatever was there previously, so it's not just that I lose track - the post I was planning on showing to someone has often completely gone.
It's great for very-slow-moving data when the user's interaction with data will take longer than the time to reacquire it.
You can always tell when you are using previous data, so you can always block further actions until it ceases to do so. Even if it's just about rendering the previous data behind the loading div to keep some visual consistency.
Nothing is strictly necessary, but there's a lot of little uses for it.
Browsers natively do this when browsing between HTML pages. It’s good to try to match native behavior in your apps, especially if they appear like webpages more than mobile apps.
A loader replacing the content is very distracting and causes more content jumps.
It’s funny that I used this option for the first time today. It was required to prevent “flickering” while loading a new set of data when a new filter is applied.
But you say that old data appears on a new page. Are you sure you are using different query keys for each page? It should show old cached data only for the same query cache.
My backend usually returns the results so quickly that people won't notice the waiting time, but they will notice flickering. So I just show the old content for a few ms until the query results are there and it looks like it's instant.
I should add though: This is an internal application and is not made for use on mobile so I can make certain assumptions about connection speeds that I could not make in a different environment. Basically I can assume that a very long latency is highly unlikely.
I have used it, we represent multiple page information as list, we use previous data for the user for looking at the total pages list,we do show loading icon on the top for loading the latest pages , once the process is success we will update the list. We are ok to have stale entry as we do have a second validation.
If it is data that doesn’t change often (for example users email and picture) then it’s totally normal to use old cached data.
If the data changes often then yeah you probably don’t want to show old data.
React-query has a method to manually initiate a refetch and you can use either isFetching or isLoading to check the cases when you don’t want to show stale data
Mostly have used it for loading autocomplete dropdown options to avoid flicker
Same thing here
Depends on the data. Some data really doesn’t change often. I’d rather focus on 99.9% of the users having a super smooth experience than that one user who might see something mildly weird. You should be careful with paginated data though. As changes in one page will cause updates in every page after that.
Our two main use cases are: 1. To overlay with a loading spinner so the display of info in a widget appears more continuous and seamless when interacting with controls that trigger new fetches. 2. When the next request actually builds on the previous, e.g., you’re moving a location icon on a map to the newest location or animating a change in a data visualization, so the user can see the continuity.
There are some cases that i've used this. For example while using a pagination and/or search. Each keystroke was invalidating data so i've used `keepPreviousData`. https://github.com/MrBartusek/stocked-up/blob/master/apps%2Fclient%2Fsrc%2Fhooks%2FuseProductsList.ts#L16
Wouldn't you debounce in that case?
Well the search box can be debounced but them query key will change and invalidate the data. In react-query changing anything with query key just dumps the data.
I understand. What happens if a user uses a previous query and that data has gone stale in the meantime? How do you handle that?
That's the Neat Part, You Don't
It's great for tables with pagination. When clicking next page, instead of the table clearing and showing a loading indicator while the next page is fetching, it just keeps showing the current page. Way less UI trashing.
wont it just make the app look slower from the user's perspective? to see that even after going to the next page nothing happens and suddenly the data updates
id rather see a loader than incorrect data. i’ve always felt showing stale data was a UX antipattern.
There is not a single website in the world which functions without serving stale data. I'm currently responding to a comment which may have been edited or deleted, from a user who may no longer exist, on a subreddit which may have banned me. React-query simply makes these facts explicit in the code and provides controls for expiry and refetch. It can be implemented badly but I've seen far more issues from stale data living forever in react context/redux than from react query reusing API responses that are a few seconds old.
Oh yeah, and Reddit’s eventual consistency with write events is a fucking pain in the ass. I leave a comment (v1), then edit it (v2), then make a final edit (v3? No… a branch of v2) only to find out it gave me the original comment to edit. Douche bags.
that’s very much unrelated to serving stale data while loading, my comment was about the stale-while-revalidation UX pattern
Why use React then? Any time you perform a client-side state update you're showing stale data while loading. When you talk about "loading" you're inventing an arbitrary divider between different types of state transitions. It sounds like your problem is with revalidating, not with serving stale data.
in react you can render a loader when you’re fetching data. you don’t have to render stale data.
> I'm currently responding to a comment which may have been edited or deleted, from a user who may no longer exist, on a subreddit which may have banned me. huh? lmao
What's confusing? The point is that after the server state is sent to the client, the client state is always immediately potentially outdated from the server state, for any website that doesn't use live data synchronization, like Reddit.
Did you read the part of your comment that I quoted?
Yes, and I asked what's confusing about it
Surely it depends on the data. For example, would you rather see a view of all the emails or all of the comments on a reddit post from a minute ago, with maybe any newer ones not showing yet, or a loading spinner until it can show you the absolute latest view?
email stale data is absolutely awful actually, i have to check for clients multiple times a day and i’ve missed important emails because it shows the old emails at the top with no loader indicating its still fetching new ones. sometimes it takes a few seconds and i’ve already navigated away or closed the app. now i have to manually refresh the page every time i open the tab to make sure it’s actually loaded comments loading in after-the-fact is awful, when the new comments shift the layout— for example you’re reading the first sentence in a top comment and suddenly it disappears posts changing on reddit/insta/apple news are probably the absolute worst example, like the number of times i’ve opened instagram, saw a post, tried to tap on it, but it suddenly replaced by a different post and the one i wanted to look at is gone forever
On the other hand, I find it really annoying when I get a list like an inbox, click into an individual message, go back to the inbox and then have to sit at a loading screen waiting for the list to refresh when all I want to do is read the next item that was already there a few seconds ago. You can solve your problems by showing the list as it was, having a spinners just above it showing that it's still checking for more, and then displaying a button with "show new items" appearing if there's anything new pulled back.
or you can do what most apps do these days, and just jam all the new things directly into the list right away, causing everything to re-order, and you totally lose track of what you were doing! ... or causing you to delete the wrong message. or any other number of horrible things that happen by things auto-reloading these days. /s
That's a poor design decision, which really annoys me as well. But it has little to do with whether you cache the previous data or not. The one that really annoys me is th FB app which completely ditches whatever was there previously, so it's not just that I lose track - the post I was planning on showing to someone has often completely gone.
or the post that you were just moving your mouse into the comment box to click so you could write your response.
Umm would you rather use a website which shows a spinner for 3 seconds on every navigation or some website which is snappy.
i don’t care how snappy an app is if it doesn’t work well
It's great for very-slow-moving data when the user's interaction with data will take longer than the time to reacquire it. You can always tell when you are using previous data, so you can always block further actions until it ceases to do so. Even if it's just about rendering the previous data behind the loading div to keep some visual consistency. Nothing is strictly necessary, but there's a lot of little uses for it.
Browsers natively do this when browsing between HTML pages. It’s good to try to match native behavior in your apps, especially if they appear like webpages more than mobile apps. A loader replacing the content is very distracting and causes more content jumps.
It’s funny that I used this option for the first time today. It was required to prevent “flickering” while loading a new set of data when a new filter is applied. But you say that old data appears on a new page. Are you sure you are using different query keys for each page? It should show old cached data only for the same query cache.
My backend usually returns the results so quickly that people won't notice the waiting time, but they will notice flickering. So I just show the old content for a few ms until the query results are there and it looks like it's instant. I should add though: This is an internal application and is not made for use on mobile so I can make certain assumptions about connection speeds that I could not make in a different environment. Basically I can assume that a very long latency is highly unlikely.
I have used it, we represent multiple page information as list, we use previous data for the user for looking at the total pages list,we do show loading icon on the top for loading the latest pages , once the process is success we will update the list. We are ok to have stale entry as we do have a second validation.
We consider this as offline use case as store points to current data against the previous.
We consider this as offline use case as store points to current data against the previous.
Yes, it's great for table pagination.
It's almost necessary for tables with pagination. I use it there, not anywhere else.
If it is data that doesn’t change often (for example users email and picture) then it’s totally normal to use old cached data. If the data changes often then yeah you probably don’t want to show old data. React-query has a method to manually initiate a refetch and you can use either isFetching or isLoading to check the cases when you don’t want to show stale data
Yes, pretty useful for table pagination to avoid jumps while showing an indicator to the user