How to manage cached pages in Vue

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

The built-in <keep-alive> component in Vue can help us significantly improve the speed of secondary page access when developing SPA applications by caching all route pages (of course, we can also cache some pages in a targeted manner), but it also brings us troubles in some scenarios, including two main contradictions:

1. How to destroy cached pages at the right time (the keep-alive component provides three parameters to dynamically configure the cache status, but the effect is limited, which will be analyzed later)
2. How to cache multiple different pages (same page with different parameters) in the same path, such as Taobao product page continues to jump to another product page

This article mainly discusses these two issues, which will be referred to as Question 1 and Question 2 in the following text.

This article assumes that all pages are keep-alive

Problem 1: Destruction

As the business logic becomes more complex, the routing stack gradually increases. In theory, users can route infinitely. Inevitably, we need to manage the page data cached in memory. The page data consists of two parts, the Vue instance and the corresponding Vnode. See the definition of cache in src/core/components/keep-alive.js in the Vue source code

 this.cache = Object.create(null) //Used to cache vnode cache[key] => Vnode
 this.keys = [] //Used to record the key of the cached vnode

After caching, the Vnode will not be reused, but only the Vue instance mounted on it will be used.

if (cache[key]) {
 vnode.componentInstance = cache[key].componentInstance //Get the Vue instance only from the cached vnode and hang it on the new vnode // make current key freshest
 remove(keys, key)
 keys.push(key)
}

Why not? Because there is a BUG. The earliest version of the implementation does use the cached Vnode directly.

From src/core/components/keep-alive.js init version

export default {
 created () {
 this.cache = Object.create(null)
 },
 render () {
 const childNode = this.$slots.default[0]
 const cid = childNode.componentOptions.Ctor.cid
 if (this.cache[cid]) {
  const child = childNode.child = this.cache[cid].child //Get the cached vnode directly
  childNode.elm = this.$el = child.$el
 } else {
  this.cache[cid] = childNode
 }
 childNode.data.keepAlive = true
 return childNode
 },
 beforeDestroy () {
 for (const key in this.cache) {
  this.cache[key].child.$destroy()
 }
 }
}

What we need to manage is actually cache and keys. Keep-alive provides three parameters to dynamically manage cache:

include - Only components with matching names will be cached.
exclude - Any components matching the name will not be cached.
max - The maximum number of component instances that can be cached.

Their functions are very simple, and the source code is also simple and easy to read:

So when we want to manage these caches, the simple solution is to operate these three parameters, modify include and exclude to cache or clear certain caches, but it should be noted that they match the name of the component:

From src/core/components/keep-alive.js

const name: ?string = getComponentName(componentOptions)

Therefore, clearing the cache will indiscriminately clear all instances of a component, which obviously does not meet our needs.

The logic of max is to clear the cache at the bottom of the stack when the maximum value is exceeded.

From src/core/components/keep-alive.js:

if (this.max && keys.length > parseInt(this.max)) {
 pruneCacheEntry(cache, keys[0], keys, this._vnode)
}

We need to solve problem one. The official API does not work, so we have to do it ourselves. We need to solve two sub-problems:

1. When to destroy
2. How to destroy
   

1. How to destroy

Let's first see how to destroy it. If you want to destroy an instance, it's very simple. You can directly use this.$destroy(). Is this okay? No, the original vnode and key are still retained in the cache and keys. There will be problems when you visit it again. The vnode is always retained, but the instance on it has been destroyed. At this time, a vue instance will be created again during the update process of vue. That is to say, as long as a keep-alive page calls this.$destroy() once, but the cache array is not cleared, this page will definitely be re-created when it is re-rendered, and of course the entire life cycle will be re-started. The final phenomenon is that the page is like it is not cached.

this.$destroy(); //Not suitable for keep-alive components

Therefore, destruction requires clearing both the cache and keys. The following defines a $keepAliveDestroy method that clears the cache at the same time:

 const dtmp = Vue.prototype.$destroy;
 const f = function() {
 if (this.$vnode && this.$vnode.data.keepAlive) {
  if (this.$vnode.parent && this.$vnode.parent.componentInstance && this.$vnode.parent.componentInstance.cache) {
  if (this.$vnode.componentOptions) {
   var key = !isDef(this.$vnode.key)
   ? this.$vnode.componentOptions.Ctor.cid + (this.$vnode.componentOptions.tag ? `::${this.$vnode.componentOptions.tag}` : '')
   : this.$vnode.key;
   var cache = this.$vnode.parent.componentInstance.cache;
   var keys = this.$vnode.parent.componentInstance.keys;
   if (cache[key]) {
   if (keys.length) {
    var index = keys.indexOf(key);
    if (index > -1) {
    keys.splice(index, 1);
    }
   }
   delete cache[key];
   }
  }
  }
 }
 dtmp.apply(this, arguments);
 }
 Vue.prototype.$keepAliveDestroy = f;

2. When to destroy

So when is it destroyed? There are two triggering times:

1. When replacing, page A --replace--> page B (clear page A)
2. When routing back, page A --push--> page B --back--> page A (clear page B)
   

replace is relatively simple. We can directly intercept the replace method of the router and clear the current page in this method. (There are exceptions here, such as when switching tabs, which will be mentioned last)

Let's take a closer look at the route back situation. If there is a back button on our page, then this is the right time to clear the cache. However, we cannot ignore the browser's built-in back button and the physical back button on Android phones. After taking this into consideration, the solution of using only the back button is not enough.

2.1 Solution 1: Use route.query to record the current page stack depth

Each push or replace adds a parameter to the query to record the current depth.

this.$router.push({
 path:"/targer",
 query:{
 stackLevel: Number(this.$route.query.stackLevel) + 1 	
 }
})

This solution has obvious drawbacks. It is very ugly and dangerous to expose a parameter externally. Users can modify it at will. When promoting a website, the promotion link copied by the business to the production environment may also have a strange suffix of https://xxx.com/foo?bar=123&stackLevel=13. Deprecation

2.2 Solution 2 uses the Vue instance itself to record the current stack depth

After hacking the push and replace methods of the router, a _stackLevel can be mounted on the vm of the target page every time the page jumps. This solves the problem of solution one. It is not exposed to users, is not visible in the URL, and cannot be modified. However, we cannot ignore another demon in the browser - the refresh button. When refreshing, the URL will not change, but the vm instance needs to be recreated, so our stack depth mark will be lost. Deprecation

2.3 Solution 3: Use history.state to record stack depth

Then the final result is that it can be invisible to the user and can be saved when refreshing. That is history.state, so what we need to do is save the stack depth to history.state, which can completely save the entire routing chain.

When we find that the target page stack depth is less than the current page, we can destroy the current page.

if (target.stack < current.stack) {
 current.$keepAliveDestroy();
}

Problem 2: Cache multiple instances of the same page with different parameters

You can see src/core/components/keep-alive.js in the source code

const key: ?string = vnode.key == null
 // same constructor may get registered as different local components
 // so cid alone is not enough (#3269)
 ? componentOptions.Ctor.cid + (componentOptions.tag ? `::${componentOptions.tag}` : '')
 : vnode.key
 if (cache[key]) {
 vnode.componentInstance = cache[key].componentInstance
 // make current key freshest
 remove(keys, key)
 keys.push(key)
 } else {
 cache[key] = vnode
 keys.push(key)
 // prune oldest entry
 if (this.max && keys.length > parseInt(this.max)) {
  pruneCacheEntry(cache, keys[0], keys, this._vnode)
 }
 }

If a vnode has no key, the component name will be used. Therefore, the key in the default cache is the component name. If the components are the same, we can solve this problem by giving each page its own key. How can we achieve that each page has its own key? There are two sub-questions:

1. How to be unique
2. How to assign key to the vnode of the page
   

1. How to be unique

1.1 Timestamp, large random number

key = Date.now()

1.2 Routing stack height + path name

key = vm._stack + router.currentRoute.path This solution uses the current stack height + path name. Why is the path name needed? Because the stack height remains unchanged when replacing, only the path name changes.

2. How to assign a key to the vnode of a page

There are currently two solutions to assign a value to the key of the current Vnode of vue-router:

2.1 Dynamically bind keys via route.query

This solution is relatively simple to implement

// Bind key
...
<router-view :key='$route.query.routerKey' />
...


//When pushing this.$router.push({
 path:"/foo",
 query:{
 	routerKey: Date.now() //Random key
 }
})

This method is very simple and effective, but the disadvantage is that it will also expose a strange parameter in the URL

2.2 Directly assign values ​​by obtaining Vnode

At which stage is the key of Vnode assigned? The answer is obvious. Before the keep-alive component render function enters, src/core/components/keep-alive.js

...
 render () {
 const slot = this.$slots.default
 const vnode: VNode = getFirstComponentChild(slot)
...

We can hack the keep-alive render function, then get the first child node in the slot, assign a value to its key, and then call the keep-alive render:

const tmp = vm.$options.render //vm is a keep-alive component instance
vm.$options.render = function() {
 const slot = this.$slots.default;
 const vnode = getFirstComponentChild(slot) // vnode is a keep-alive-component-vnode
 if (historyShouldChange) {
 if (!isDef(vnode.key)) {
  if (isReplace) {
  vnode.key = genKey(router._stack)
  } else if (isPush()) {
  vnode.key = genKey(Number(router._stack) + 1)
  } else {
  vnode.key = genKey(Number(router._stack) - 1)
  }
 }
 } else {
 // when historyShouldChange is false should rerender only, should not create new vm ,use the same vnode.key issue#7
 vnode.key = genKey(router._stack)
 }
 return tmp.apply(this, arguments)
}

Summarize

Through the above analysis of the problem, we have solved the core problem of automatic cache management. This article is a summary of the open source library vue-router-keep-alive-helper. This library is a simple and easy-to-use keep-alive cache automation management tool, which will bid farewell to the Vue cache management problem. If it is useful to you, thank you for your generous Star.

Demo Sample Code

Thanks for the Bilibili demo video.

The above is the details of how to manage cached pages in Vue. For more information about vue cached pages, please pay attention to other related articles on 123WORDPRESS.COM!