How can I show a refreshing state without replacing the content already on screen?
Quick answer
Track whether usable results exist separately from whether a request is running. On the first load, show a loading state in place of results. When refreshing existing results, keep them visible and add a clear progress message. If the refresh fails, stop the progress indicator, retain the previous results, and explain that they could not be updated. Offer a retry if the interface supports one.
The question, the details, the next step.
I have a results screen that reloads when someone pulls to refresh or changes a filter. How do I show activity without blanking the results?
Track two things separately: whether usable results are available, and whether a request is running. If one loading flag controls the whole screen, starting a refresh can accidentally replace useful content with a spinner.
Use two display modes:
- Initial load: No results are available yet, so show a loading message or placeholder in the results area.
- Refresh: Results are already available, so leave them on screen and show a nearby indicator such as “Updating results…”.
The key distinction is whether there is content to preserve. A refresh indicator should communicate that an update is underway without making the current results disappear.
What should the screen show on the first visit, before any results arrive?
Show a loading message in the results area rather than an empty list that might look like a completed search with no matches. For example:
Search results
Loading results…When the request finishes, show the returned results. If it finishes successfully with no matches, replace the loading message with a distinct empty state, such as “No results found. Try changing your filters.” This separates waiting from a completed search that returned nothing.
For a later refresh, keep the existing results visible while the request runs. If the user changes filters, make clear which filters the visible results represent; old results displayed under new filter labels could be misleading.
How should I decide what to render, including when a refresh fails?
First check whether results are available; then show the state of the current request. For example, if a results screen already has data, it can show “Updating…” above the results during a refresh. If that request fails, stop the progress message, retain the results, and show “Couldn’t update. Showing previous results.” Offer a retry if another attempt is available, and don’t imply the displayed data has been refreshed.
A first request that fails is different: there are no previous results to keep on screen. Show an error and a retry option in the results area instead of leaving a loading message indefinitely.
A simple rendering sketch:
No results + request running → Loading results…
No results + request failed → Couldn’t load results. Try again.
Results available + refreshing → Keep results; show Updating…
Results available + refresh failed → Keep results; show update failure
Results available + refreshed → Show new results; clear statusHow can I check that the status message and results make sense together?
Walk through each transition. “Updating results…” should mean a request is underway, not that the visible results have already changed. When new results arrive, show them and clear the progress message. If an update fails, stop indicating active progress and explain that the displayed results are previous results.
Keep the indicator near the results so its meaning is clear, without covering them. If the screen has a refresh control, make sure its status does not suggest completion before the update finishes. Check the first-load failure, successful empty result, refresh success, and refresh failure states using your own content and layout.
A practical checklist
Track whether usable results exist separately from whether a request is active.
Show a loading state in the results area before the first results arrive.
During refresh, keep existing results visible and add a nearby progress message.
Distinguish a completed empty result from a request that is still loading.
On refresh failure, retain and identify the previous results; offer retry if available.
Clear the progress message when the request succeeds or fails.
A few more useful answers
Should I dim or cover the results during refresh?
Keep the existing results readable and avoid covering them with a blocking progress display. If a particular action must be unavailable during the update, communicate that separately.
What if the first request succeeds but returns no results?
Show a completed empty state, such as “No results found,” rather than a loading message. This makes clear that the request finished.
What should happen after a refresh fails?
Stop the progress indicator, keep the previous results visible, and say they were not updated. Provide a retry action if the interface supports another attempt.