In 2026, with keep-alive preserving filters and scroll position on a list page, should you refetch every time you return from detail when the data is still stale?

Most of the time, this is not because the keep-alive cache was not cleared properly. It is because keep-alive caches the entire component instance: filters, pagination, and scroll position remain in memory, while the list data was requested only once in mounted (or at the setup top level). Once the component is reused, those hooks no longer fire, so you see filters still there but data that is stale. A common delivery practice with Vue 3 + Vite in 2026 is to keep filters and scroll position, and decide in activated whether to refetch based on a time window or a dirty flag, rather than turning off caching and rebuilding the whole page.

Why filters are still there but data is stale after returning

keep-alive reuses the component instance, not a DOM snapshot. When the component is first entered, it goes through created → mounted; after it is cached, entering again only triggers activated, and mounted does not run again. So where you put the request determines what you see when you return.

• The request is written in mounted or at the setup top level: it runs only on the first entry, so when you return, the data stays at the moment you left.
• The request is written in activated: it runs on every entry, and clicking back twice will refetch each time, which easily stacks requests on weak networks.
• The request is written in a watch on route params: it does not trigger if the params do not change, and when returning from detail the params often do not change.

Another common cause is that filter conditions exist only in a ref inside the component and are not synced to the route query. When the cache is restored, the conditions are still there, but the same record may already have been changed on the detail page, so the two sides do not match. What users see does not look like a broken cache; it looks like the same data is stored separately in two places.

First decide whether to cache, then decide how to refresh

Half of the caching problem is whether to refresh, and the other half is whether to cache at all. Answering the latter first can save half the patches. The following order is fairly common in projects; reversing it often means writing code first and then reworking it.

1. Is this page's state worth keeping? Do filters, pagination, scroll position, and form drafts belong to an operation the user is currently doing? Purely display-oriented and strongly real-time pages do not need caching.
2. How many instances should be cached? When the same route has different query values, is sharing one instance allowed? The most common consequence of sharing is that filter conditions bleed into each other.
3. When does the data count as expired? Whether to use a time window, a dirty flag, or changes in dependent params must be decided before writing code; otherwise activated will be filled with if statements.
4. What should be cleaned up on exit? Polling, timers, and large object references should be stopped in deactivated when they should stop.

Among these four steps, steps 1 and 3 determine whether complex logic is needed later. In practice, as long as you can clearly state what the user wants to continue viewing when they return, the condition for step 3 usually takes only two or three lines to write.

Should you refetch on return: three approaches compared

No single approach fits every page; the differences are mainly in experience, request volume, and maintenance cost. Below is a comparison based on 2026 project delivery habits. The durations are an experience range and depend on page complexity.

• Reuse with keep-alive + decide in activated whether to refetch: returning is smooth, and scroll position is naturally preserved; the cost is that you must manage data freshness yourself. Typical range is 0.5 to 2 person-days, including regression testing.
• No caching, rebuild every time: data is always fresh and the code is simple; the cost is lost scroll position and more requests, with a noticeable blank-screen feel on weak networks.
• Sync filters to the URL + do not cache the component: links are shareable and forward/back navigation works normally; the cost is that you need param serialization and default-value handling, and scroll position still needs extra work.

For list pages with multiple tabs, multiple filters, and infinite scroll, adding caching and freshness checks commonly takes 2 to 5 person-days; if you also need to support scroll position restoration in low-end Android WebView, a slightly longer duration is normal.

When it fits and when it does not

It fits: list → detail → return browsing flows, switching back and forth between tabs, multi-step forms, and long lists where scroll position must be preserved. In these scenarios, the user's core need is to continue viewing from the same screen as before; caching saves not only requests but also the cost of relocating.

It does not fit: strongly real-time pages such as inventory, order status, instant messaging, and collaborative editing; pages that are very light and load in one screen; and compliance-related pages where the state must always come from the latest server value. In these cases, the compensating logic added for caching is often more expensive than the requests saved.

A standalone boundary judgment: whether a list page should be cached depends not on page complexity, but on whether the user needs to continue viewing the same screen when returning; if not, there is no need to use keep-alive.

Pre-launch acceptance and delivery experience

A common situation in projects is that the requester wants the list not to jump to the top when returning, but the API still lacks an updated-time field, and the schedule is tight. The approach is to use a frontend timestamp as a fallback, refetch in activated after 2 minutes, and write a dirty flag after the detail page submits successfully; the cost is an occasional extra fetch, but it avoids the rework of restoring scroll position after simply disabling caching, and it also saves a post-launch UX revision. The typical range for this kind of refresh interval is between 30 seconds and 5 minutes, set according to business real-time needs. This is more practical than pursuing absolute accuracy.

At delivery, check these items:

• When returning to the list, filter values, pagination, and scroll position match those before leaving.
• After submitting successfully on the detail page and returning, changes are visible in the list's row count or status labels.
• After entering and leaving more than 10 times in a row, the number of list requests stays within a reasonable range and does not multiply.
• After leaving the page, polling and timers have stopped, and there are no residual requests in the network panel.
• After logging out and logging back in, you cannot see the previous user's filter results and data.

Common pitfalls on the ground: sending requests unconditionally in activated makes caching pointless; not setting a max limit means component instances only grow when multiple tabs are opened repeatedly; include matches by component name but the component has no name, so development shows no error and caching silently fails, which is easily mistaken for a framework issue; forgetting to stop polling in deactivated shows up during integration as requests appearing out of nowhere. When you need a basis, check the keep-alive and lifecycle hook explanations in the official Vue documentation, then confirm item by item against the delivery acceptance checklist.

FAQ

When keep-alive wraps router-view, why do some pages work and others do not?

Most often, include matches by component name, but the component has no name or uses the filename; the development environment shows no error, and the page simply is not cached silently.

Scroll position is still lost after returning to the list. Does that mean caching did not work?

First confirm whether the component is actually reused. If it is reused but still jumps to the top, it is often related to the choice of page scroll container, or the global scrollBehavior forces a return to the top every time.

Why does the number of requests double when refetching data in activated?

A common reason is that activated and a watch trigger at the same time, or a parent component is also fetching the same data. First consolidate manual refreshes into one place, then decide whether a refresh is needed.

After a list page is cached, can the next person see the previous user's data after logging out and back in?

Yes. If logout only clears the token and not the cache, a common practice is to actively clear cached instances in the logout flow, or reload the whole page once.

If the same route differs only in query, can it share one cached instance?

Not recommended. Sharing will mix filter conditions together and is hard to reproduce in test environments; a common practice is to distinguish caches by query key, or simply not cache that page.

If a list already shows filters still there but data that is stale, do not rush to turn off caching. Write the refresh decision as a small condition in activated, then run through the acceptance criteria above. The boundary is clear too: for strongly real-time, lightweight, or compliance pages that require the latest value every time, not caching at all is simpler. When multiple people collaborate on a team, writing this judgment into the delivery checklist is more reliable than word of mouth. Xiyue Company also checks in this order when taking on revisions of this kind of page.