Custom cache strategy and matching rules for KeepAlive

[HcySunYang]

Discussion Thread for "Custom cache strategy and matching rules for KeepAlive"

Links

• RFC Proposal
• Full Rendered Proposal

[wuyuweixin]

We really need these features.

[wuyuweixin]

Hope to merge soon.

[posva]

This is nice.

I'm only worried about the pruneCacheEntry(): it's added later on which makes it easy to call before it exists and also harder to type.
It's also weird to be able to only call that function but not all the other ones that were added by the user manually.

Wouldn't it be possible to only have the delete() method and let Vue wrap it at runtime? This would make it always callable.

Another solution would be calling a method on the KeepAlive component with a ref but I'm unsure this is feasible and it's not a good practice anyway

What was the point of adding onBeforeActivate()? There is nothing on the motivation section about them

[tony-gm]

Yes, there is no reason to override or add another hooks base on any current API lifecycle hooks.

[hezhongfeng]

In vue2.x I can custom a component to replace KeepAlive.But in vue3.x its impossible.
Looking forward to this feature

[yuntian001]

vue3 不能替换但是可以用自定义组件 实现 已经有人这么干了https://juejin.cn/post/7140068886598123557

[cchangwen]

为什么不通过 vite 替换源码

[cchangwen]

替换源码是真的爽到家了
function pruneCacheEntry(key) {
to
sharedContext.prune = function pruneCacheEntry(key) {

[cchangwen]

https://cn.rollupjs.org/plugin-development/#transform

[Caleb-Xu]

I realy realy need it, otherwise I would need to change a lot of project code 😢

[wcldyx]

现在可以用了吗

[pavlexander]

Hello, I have to say in advance that I don't quite understand the proposed solution fully. It looks too complex for the task that I/other people want to accomplish based on what I have read (vuejs/core#2077, https://stackoverflow.com/questions/70113769/manually-remove-and-destroy-a-component-from-keep-alive, https://stackoverflow.com/questions/65163775/how-to-destroy-unmount-vue-js-3-components, https://stackoverflow.com/questions/68995879/vue-3-force-unmount-when-deactivated) to name a few.

The current situation is - most of the solutions ether involve using $destroy() method which is now obsolete in vuejs3 or rely on using if-else conditions for keep-alive component itself or do not actually solve the problem at all or rely on low-level hacks (which I was not able to replicate in latest vuejs3 version) therefore are obsolete..

For example, if we have cached instances of the same Item component (path: /item/{id}) , that are cached based on $route.fullPath as a key:

      <router-view v-slot="{ Component }">
        <keep-alive :include="Item,SomethingElse">
          <component :is="Component" :key="$route.fullPath" />
        </keep-alive>
      </router-view>

Given that we visited the page 3 times under different IDs:

• /item/1
• /item/2
• /item/3

Would the proposed solution allow to destroy/unmount a specific instance upon an event in app? Let's say user removed the item from the database so we want the cache of /item/2 to be cleared and never shown again - how do you accomplish it with proposed solution?

Overall it would be good to know when the solution will be implemented (or the latest status of it), given that after 2 months it's going to be a year since this topic was created.

Edit (19.01.2022)

In addition to above, I would also like to empathize on required (personally required/subjective) caching customization granularity. If I understand correctly - :max directive only allows setting the maximum general allowed number of cached pages.

So let's say we have 3 components we want to cache

• ListOfItems
• Item/{id}
• Profile

If we set (currently) maximum to 1 then every single component is allowed to have 1 cached instance. Is this correct?

In comparison, in real world scenario, for the ListOfItems and Profile we would only want/need 1 single instance of the page to be cached. But for Item - there could be many items with different Ids, so the non-1 limit would be set. An example in my original post clearly explains the idea. So, if there is no in-built way to control the maximum number of cached components PER COMPONENT, then I think it would be good if the developers were given a tool to explicitly (manually) enforce the rules of caching. I.e. allow to write a custom function/logic - when the number of cached Item components exceeds X - drop previously cached Item components.

[yuntian001]

通过key判断更新缓存已经有人实现了 https://juejin.cn/post/7140068886598123557

[tony-gm]

I have another solution, it's mini change for current API and easy to implement.

1. Provide a composoable function createKeepAliveCache, return a KeepAliveCache object.

export interface KeepAliveCache {
  include: Ref<MatchPattern | undefined>
  exclude: Ref<MatchPattern | undefined>
  max: Ref<number | string | undefined>
  cache: Map<string, VNode>
  remove: (key: string) => void
  clear: () => void
}

2. KeepAlive component, provide a new prop named cache, then user can v-bind to createKeepAliveCache() returned KeepAliveCache object.

3. User can change include,exclude,max to maniplate cache as current API (since it's a Ref), also remove(key) can remove a cache by key, clear() to clear all cache.

Here is a full example

<template>
  <button @click="onCloseTab">Close Current Tab</button>
  <button @click="onCloseAllTabs">Close All Tabs</button>
  <router-view v-slot="{ Component, route }">
    <keep-alive :cache="pageCache">
      <component :is="Component" :key="route.fullPath" />
    </keep-alive>
  </router-view>
</template>

<script lang="ts">
import { defineComponent, createKeepAliveCache, ref } from 'vue'
export default defineComponent({
  name: 'App',
  setup() {
    const currentPath = ref('')
    const pageCache = createKeepAliveCache()
    pageCache.include.value = ['Component1']

    function onCloseTab() {
      pageCache.remove(currentPath.value)
    }

    function onCloseAllTabs() {
      pageCache.clear()
    }

    return {
      pageCache,
      onCloseTab,
      onCloseAllTabs
    }
  }
})
</script>

I document this in a RFC , more detail please check RFC Link

And I also did a prototype implement base on this RFC, currently it's work. Implement Link

[tony-gm]

Any plan about this keep-alive RFC?

[yokiyokiyoki]

呜呜 请官方下场看看，很久了

[blakjak44]

Adding my vote for this feature

[a145789]

really need beforeDeactivate, it's really useful, any results?

[Sackeys]

I'm waiting this too for managing component states easier, I hope we'll see this feature coming this year. <3

[RobertHunter-Pluto]

To anybody still interested in this, I found a way of making it work, although it's still not super great. I'm on Vue 2.7.10 and vue-router 3.6.5.

App.vue doesn't require anything special, just a <router-link> without using $route.fullPath for a key.

The parent component within the top level router-link contains this:

<keep-alive>
  <router-view> </router-view>
</keep-alive>

max, exclude, include can be whatever you like, but don't key it based on the fullpath and don't set :max=1.

The trick is in whatever component you're rendering as a child with multiple versions, for example item/1 item/2 item/3.

Add a :key inside of the child component based on the item number, which should be supplied by the route, either inside of data or as a computed. Then watch the route itself and change the key to any new value that gets supplied. Changing the key will trigger a re-render of the child content and everything else will work as expected.

<child :key=tag></child>
...
created() {
    this.tag = this.$route.params.tag;
  },
data() {
    return {
      tag: null,
    };
  },
watch: {
    "$route.params.tag"(value) {
      // preserve back functionality, only re-render if the value is new
      if (value === undefined || this.tag === value) {
         return;
      }
      this.tag = value;
    },
  },

All of this needs to happen inside whatever is being displayed in the router-link.

There definitely needs to be a better API for managing cached state, but at the very least this avoids the most common pitfalls of having multiple child components clog up memory and ignore whatever :max you've set.

[fduser1]

I agree with @pavlexander. Many of the RFC's referenced issues (and what brought me here today) are tied to the simple fact that Vue 3 has no way to remove a single component from keep-alive's cache as we could indirectly with Vue 2's component $destroy() method.

While I appreciate the RFC author is trying to address multiple cache issues including this missing Vue 3 cache capability, the proposed RFC change is substantial and we are not seeing any incremental cache improvements because they are all tied to one big overhaul change to caching.

I think we should try to break down caching changes; as a start, at least into two parts (1) address control of removing a single item and (2) fine-grain cache control (e.g. implementation, hooks). In my opinion, #1 is a core capability of KeepAlive or any caching system.

As a suggestion on how to implement #1, we could employ the provide/inject mechanism of Vue 3 here. (Vue 2 is reaching EOL soon and is out-of-scope at this point.) KeepAlive component can provide some cache-service object and any enclosing component can inject this object. As a start, the cache-service object can provide one simple method that the component can use to remove items including itself; e.g. injectedCacheServiceObject.remove(this).