Vue: J'espère que keep-alive peut augmenter la fonction de suppression dynamique des composants mis en cache

Créé le 4 sept. 2017  ·  49Commentaires  ·  Source: vuejs/vue

Quel problème cette fonctionnalité résout-elle ?

Lorsque j'utilise vue en tant qu'application d'une seule page, lorsque plusieurs fonctions sont commutées, j'espère obtenir l'effet de créer dynamiquement des onglets pour la commutation.Comme l'iframe précédent, ces onglets sont keep-alive, mais s'il y a trop de keep- lives Quand, l'utilisation de la mémoire du navigateur sera trop importante. J'espère qu'il y a au plus dix onglets commutables, par exemple, le précédent, j'utiliserai le programme pour fermer automatiquement les onglets correspondants et j'espère effacer les composants mis en cache en conséquence.

A quoi ressemble l'API proposée ?

Par exemple : vm.$clearKeepAlived(routerName)

feature request

Commentaire le plus utile

En voyant la méthode de $destroy, je pense que c'est l'utilisation correcte, qui détermine s'il faut mettre en cache le composant lorsque vous quittez la page via différents comportements d'utilisateur dans le composant.
(Par exemple, un composant de message, ce composant doit être détruit une fois le message soumis avec succès. S'il n'est pas soumis, le cache doit être conservé pour que l'utilisateur puisse entrer et continuer la prochaine fois.)
Cependant, après la destruction, répéter l'accès à ce composant produira des résultats étranges et le composant ne pourra plus être mis en cache.Je pense qu'il s'agit d'un bogue.

Tous les 49 commentaires

En effet, avant de répondre une fois à cette question dans le forum, vous pouvez utiliser keep-alive de include ou exclude à faire.

Pour vous écrire un exemple simple :
https://jsfiddle.net/jingkaizhao/m5tLg7wt/2/

n'est-ce pas un dup de #6259 ?

@posva Oui, situation similaire. Il est sur le point d'effacer dynamiquement le cache keep-alive pendant l'exécution.

@jkzing Merci beaucoup, votre méthode devrait pouvoir compléter le scénario que j'ai mentionné ci-dessus, mais j'ai toujours un scénario, comme une page de liste, s'il est passé à partir de l'onglet, j'espère qu'il est maintenu en vie et obtenez les données directement à partir de la mémoire, si Après avoir modifié une donnée, le programme passe à la page de liste, dans l'espoir d'obtenir de nouvelles données en arrière-plan.Bien que je puisse obtenir les nouvelles données de l'arrière-plan une fois la page terminée, j'ai l'impression pas assez élégant. S'il y a l'api ci-dessus, je n'ai besoin de le changer qu'après la modification. Le keep-alive de ce routeur est effacé, et les données devraient être automatiquement obtenues à partir de l'arrière-plan. Je ne sais pas si ce que j'ai dit peut vous faire comprendre. Bref, j'espère pouvoir faire élégamment l'application monopage comme l'effet multi-onglets de l'iframe précédent : http://www.sucaihuo .com/modals/16/1653/demo / Ci

@okjesse Cela peut également être fait, tout ce dont vous avez besoin est de mettre à niveau include ou exclude vers des composants de niveau supérieur ; ou, si vuex est utilisé, mettez include magasin vuex .

En bref, Vue fournit une API de base pour accomplir cela. Si vous voulez l'utiliser commodément, vous devez l'encapsuler légèrement.

@jkzing comprenez, merci, j'écris maintenant une implémentation keep-alive par moi-même, je vais essayer de suivre votre méthode

@jkzing , mais même si cela peut être réalisé, je pense qu'il est préférable d'avoir cette api, la sémantique sera différente, ce que je veux c'est effacer les données qui ont été maintenues en vie, le composant lui-même est toujours en vie, plutôt que non-stop si le commutateur sera vivant

Ce n'est qu'un des problèmes. L'ouverture constante de nouvelles pages que nous rencontrons causera trop de mémoire, et finalement le navigateur se bloquera. Cela ne devrait rien avoir à voir avec keepalive.Si on peut, reproduire le phénomène et le montrer à @jkzing

Ce que nous voulons atteindre, c'est décider d'utiliser la page en cache ou une nouvelle page juste avant de passer à la page.L'ancienne API ne peut pas le faire

J'ai également rencontré cette exigence. Ensuite, j'ai cliqué sur la liste des menus pour me connecter, ajouté une étiquette dans les onglets et mis en cache le composant nouvellement ouvert; cliqué sur l'étiquette de fermeture, j'espère supprimer le composant mis en cache; j'ai appelé ceci. $ dans la fonction hook désactivée du composant. destroy (); Cela peut vider le cache, mais on constate que le nouveau composant ne sera pas mis en cache lors de la prochaine ouverture de la connexion

@fadexiii J'ai résolu la méthode existante, ce qui peut être réalisé en définissant dynamiquement comprend

@okjesse Mon keep-alive contient un <router-view></router-view> La méthode include ne fonctionne pas

@okjesse Pour le moment, je n'ai pas défini l'attribut de nom de composant. Après la définition, c'est bon, merci

Pour info : implémenté dans 2cba6d4cb1db8273ee45cccb8e50ebd87191244e

@fadexiii #6961 Les mêmes besoins que vous, comment le résolvez-vous ?

@Jack-93 Utilisez keep-alive include, lorsqu'une nouvelle balise est ouverte, le nom du composant actuel est ajouté au tableau d'inclusion et le nom de composant de la balise de fermeture est supprimé du tableau lorsque la balise est fermée.

En voyant la méthode de $destroy, je pense que c'est l'utilisation correcte, qui détermine s'il faut mettre en cache le composant lorsque vous quittez la page via différents comportements d'utilisateur dans le composant.
(Par exemple, un composant de message, ce composant doit être détruit une fois le message soumis avec succès. S'il n'est pas soumis, le cache doit être conservé pour que l'utilisateur puisse entrer et continuer la prochaine fois.)
Cependant, après la destruction, répéter l'accès à ce composant produira des résultats étranges et le composant ne pourra plus être mis en cache.Je pense qu'il s'agit d'un bogue.

@wanyaxing J'ai également rencontré un problème similaire au
Dans ce cas, il n'y a pas de problème pour la première fois, et il peut fonctionner normalement. Après deux fois ou plus, B sera mis en cache plusieurs fois. Chaque fois qu'il revient de D à B, un nouveau B sera généré, et le B précédemment mis en cache est toujours dans la mémoire, comme le montre la figure :
image

Le code de base est le suivant :
image

@ realfly08 J'ai essayé de soumettre un PR pour résoudre ce problème, mais il semble que la soumission ait compris comment passer la revue de code automatique de vue. -https :

Je me préparais également pour le cache à l'échelle du site auparavant, puis j'ai rencontré la fosse logique de la mise à jour du cache.
Maintenant, j'ai abandonné tout le cache du site, n'ai activé le cache que sur les pages de formulaire clés, puis j'ai jugé dynamiquement dans le code s'il fallait conserver les données de la page actuelle, ce qui est un saut temporaire de ces problèmes, mais je pense toujours que cela la logique ne suffit pas.

@wanyaxing J'ai également rencontré un problème similaire. La fonction logique à implémenter est les pages A->B->C 3. Le cache est utilisé lors du retour et il est restitué lors de la nouvelle entrée. Actuellement, chaque page est maintenue en vie , puis je fais un jugement sur la page B. Si c'est pour revenir à la page précédente (allez -1), détruisez le composant actuel dans désactivé et appelez $destroy. Lorsque vous entrez à nouveau dans la page C dans l'ordre, revenez à la page B , vous pouvez voir que c'est une page B recréée, il y a une page B dans le cache en même temps

@fadexiii keep-alive comment utiliser avec router-view?

  <keep-alive :include="includes">
     <router-view></router-view>
  </keep-alive>

include écrit le nom dans la configuration du routage : 'login'

const router = new Router({
  routes: [
    {
      path: '/login',
      name: 'login',
      component: Login
    }]
 })

Pourquoi est-ce que j'affecte des inclusions à une chaîne vide et qu'elle peut toujours être mise en cache ?Mon exigence est de détruire manuellement la route mise en cache

Une fois le composant détruit, le cache n'est pas vidé.Je pense que le problème est là.
Le responsable du projet recommande l'utilisation d'attributs comme include pour le traitement.Je ne pense pas qu'il soit directement détruit.La mémoire peut être améliorée.

@wanyaxing a lu le PR que vous avez soumis, il devrait être valide, ou ouvrez une API de suppression de cache, n'est-ce pas ?

@leixu2txtek J'ai abandonné ce PR. En effaçant le cache de force, j'ai réalisé la fonction de suppression dynamique du composant de cache déguisé.

J'utilise actuellement la mise en cache sur l'ensemble du site et j'implémente la fonction de suppression du cache en fonction de la logique métier en interceptant l'événement de routage de la sortie de la page.Les extraits de code suivants sont à titre de référence :

  • Mettez la router-view dans le keep-alive, et tout le site utilisera le cache par défaut.
    <keep-alive><router-view class="transit-view"></router-view></keep-alive>
  • J'ai superposé toutes les pages dans les itinéraires. Par exemple, meta.rank représente le niveau de la page, tel que 1.5>2.5>3.5 signifie entrer dans la deuxième couche de la première couche à la troisième couche.
routes: [
{   path: '/', redirect:'/yingshou', },
{   path: '/yingshou',                meta:{rank:1.5,isShowFooter:true},          },
{   path: '/contract_list',           meta:{rank:1.5,isShowFooter:true},          },
{   path: '/customer',                meta:{rank:1.5,isShowFooter:true},          },
{   path: '/wode',                    meta:{rank:1.5,isShowFooter:true},          },
{   path: '/yingfu',                  meta:{rank:1.5,isShowFooter:true},          },
{   path: '/yingfu/pact_list',        meta:{rank:2.5},                            },
{   path: '/yingfu/pact_detail',      meta:{rank:3.5},                            },
{   path: '/yingfu/expend_view',      meta:{rank:4.5},                            },
{   path: '/yingfu/jizhichu',         meta:{rank:5.5},                            },
{   path: '/yingfu/select_pact',      meta:{rank:6.5},                            },
{   path: '/yingfu/jiyingfu',         meta:{rank:7.5},                            },
]
  • Parce que toutes les pages sont mises en cache, l'idée de base est [Quand le cache sera-t-il détruit ? ]. Ma conception est la suivante : le cache de la page actuelle sera conservé lors du passage à la page suivante au même niveau, et [le cache de la page actuelle sera détruit lors du retour à la page précédente].
  • Ainsi, dans main.js, j'ai utilisé la méthode Vue.mixin pour intercepter l'événement de sortie de route et implémenté la fonction de destruction du cache de page dans la méthode d'interception. Le code de base est le suivant :
Vue.mixin({
    beforeRouteLeave:function(to, from, next){
        if (from && from.meta.rank && to.meta.rank && from.meta.rank>to.meta.rank)
        {//如果返回上一层,则摧毁本层缓存。
            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 = this.$vnode.key == null
                                    ? 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];
                        }
                    }
                }
            }
            this.$destroy();
        }
        next();
    },
});

Résumé : En fait, via le composant keepAlive de niveau supérieur où se trouve le composant de page, la liste de cache dans l'objet est violemment manipulée. . .

Simple et direct, bien que pas très élégant, il est facile à utiliser, haha ​​:)

Bien sûr, j'espère toujours que l'API de support officielle sortira mieux.

@wanyaxing je contrôle la mise en cache de la page via le routage

Par exemple, j'ai /executed/ et sa route enfant /executed/chart/. J'utilise également la méthode mixin pour pirater afin de détruire les composants qui n'ont pas besoin d'être mis en cache lorsque la route quitte. le parent au sous-ensemble.Le parent est mis en cache et les autres conditions sont détruites, nous n'avons donc qu'à contrôler le routage, sans ajouter d'attributs, je suis paresseux ;

// 支持页面保持
Vue.mixin({
  beforeRouteLeave(to, from, next) {

    if (!to.path.startsWith(from.path)) this.$destroy();

    next();

  }
});

Merci @wanyaxing , votre code m'est très utile. Permettez-moi de me référer à

J'ai découvert que le cache n'avait pas été détruit.Faites de votre mieux pour communiquer avec @LinusBorg

@wanyaxing Je cherchais un moyen d'obtenir le cache, je ne connais pas le code principal de vue, votre code est plus utile, j'ai réussi le test, très bien, faites-le temporairement, j'espère que le fonctionnaire pourra résoudre ce problème, J'ai demandé si peu de gens ont vérifié beaucoup d'informations, et il y a des problèmes de ce genre

Ha ha.
Sur cette base, @leixu2txtek vous recommande un plug-in, associé à https://github.com/wanyaxing/vue-router-then , l'effet est meilleur.
Utilisez vue-router-then pour ouvrir une sous-page sur la page actuelle, et vous pouvez obtenir les informations ou les événements de la sous-page sur la page actuelle.
this.$routerThen.push('/chose').then(vm => {})

Pour donner un exemple le plus couramment utilisé, par exemple, lorsque vous remplissez la page de commande, vous devez ouvrir la liste d'adresses pour la sélection.

<input v-model="price" v-model-link="'/select_address'" />

Puis dans la route ouverte par /select_address, après avoir sélectionné l'adresse, déclencher un événement d'entrée et revenir à la page.

<script>
methods:{
    clickSomeOne:function(value){
        this.$emit('input',value);
        this.$router.go(-1);
    },
}
</script>

Cela nécessite l'interaction directe entre le routage parent et enfant basé sur la stratégie de mise en cache mentionnée ci-dessus. Cependant, cela sera très intéressant après la mise en œuvre. L'idée de développement est très intuitive. Vous n'avez pas besoin d'envisager de stocker des données temporaires dans vuex , ouvrez simplement la page pour obtenir les données.

@fadexiii Voulez-vous dire que si vous utilisez un routeur, l'inclusion doit-elle inclure le nom dans le composant correspondant au routeur ?
---- routeur.js ----

import ComponentA from 'views/a
export default [
  {path: 'a', component: ComponentA, name: a}
]

---- vues/une.vue ----

export default {
  name: 'xxxa'
}

Qu'est-ce qui doit être stocké dans include est ComponentA ou a ou xxxa?

@yiwuyu xxxa

@jkzing Et si je charge deux fois le même composant, l'un doit être mis en cache et l'autre n'a pas besoin d'être mis en cache ? Leurs noms de composants sont les mêmes.

J'ai également rencontré ce problème.
méta : {
keepAlive : true // doit être mis en cache
}
Définir sur false lorsque vous cliquez sur Fermer
Puis changez l'auditeur en vrai
Voir https://mp.csdn.net/postedit/82628953 pour plus

Lorsque l'onglet est basculé, le cache est fermé et le cache est détruit et la prochaine fois qu'il est ouvert et rechargé avec plusieurs pages de sous-routage imbriquées, la même chose est vraie.

En effet, avant de répondre une fois à cette question dans le forum, vous pouvez utiliser keep-alive de include ou exclude à faire.

Pour vous écrire un exemple simple :
https://jsfiddle.net/jingkaizhao/m5tLg7wt/2/

Je comprends cet exemple. Je veux demander aux dieux ici. Mon entreprise est comme ça. Le côté gauche est un onglet vertical. Cet onglet peut être dynamiquement ajouté ou supprimé par l'utilisateur. Cliquez sur l'un des onglets, et le côté droit affiche celui correspondant à un arbre est en fait le même arbre, mais les nœuds sélectionnés par l'arbre sont différents. L'idée initiale est d'ajouter un élément d'onglet, d'ajouter un arbre sur le côté droit, lors du changement d'onglet, l'arbre sera masqué et affiché en conséquence (v-show), mais lorsqu'il y aura plus d'onglets, il y aura beaucoup d'arbres sur le côté droit, et les nœuds dom sont trop nombreux. Si vous n'avez pas besoin de masquer l'affichage et d'utiliser v-if, il y aura des états d'arborescence (sélectionnés, développés, défilés) qui ne peuvent pas être enregistrés, alors j'ai pensé plus tard de keep-alive, qui peut sauver l'état. Mais je suis un composant à fichier unique de vue. Les onglets sont sur la page principale. L'arborescence est un composant qui est importé. Une fois l'importation effectuée, elle est directement enregistrée dans la propriété des composants. Comment puis-je créer plusieurs noms pour l'arbre comme tu l'as posté ? ? Mais en fait, je ne suis qu'un composant. J'ai créé le nom uniquement pour l'associer à l'onglet de gauche. Plus précisément, pour supprimer un élément d'onglet sur le côté gauche, supprimez également le tampon d'arbre correspondant à cet élément d'onglet dans keepalive ? Mais que devons-nous faire ?

@leixu2txtek J'ai abandonné ce PR. En effaçant le cache de force, j'ai réalisé la fonction de suppression dynamique du composant de cache déguisé.

J'utilise actuellement la mise en cache sur l'ensemble du site et j'implémente la fonction de suppression du cache en fonction de la logique métier en interceptant l'événement de routage de la sortie de la page.Les extraits de code suivants sont à titre de référence :

  • Mettez la router-view dans le keep-alive, et tout le site utilisera le cache par défaut.
    <keep-alive><router-view class="transit-view"></router-view></keep-alive>
  • J'ai superposé toutes les pages dans les itinéraires. Par exemple, meta.rank représente le niveau de la page, tel que 1.5>2.5>3.5 signifie entrer dans la deuxième couche de la première couche à la troisième couche.
routes: [
{   path: '/', redirect:'/yingshou', },
{   path: '/yingshou',                meta:{rank:1.5,isShowFooter:true},          },
{   path: '/contract_list',           meta:{rank:1.5,isShowFooter:true},          },
{   path: '/customer',                meta:{rank:1.5,isShowFooter:true},          },
{   path: '/wode',                    meta:{rank:1.5,isShowFooter:true},          },
{   path: '/yingfu',                  meta:{rank:1.5,isShowFooter:true},          },
{   path: '/yingfu/pact_list',        meta:{rank:2.5},                            },
{   path: '/yingfu/pact_detail',      meta:{rank:3.5},                            },
{   path: '/yingfu/expend_view',      meta:{rank:4.5},                            },
{   path: '/yingfu/jizhichu',         meta:{rank:5.5},                            },
{   path: '/yingfu/select_pact',      meta:{rank:6.5},                            },
{   path: '/yingfu/jiyingfu',         meta:{rank:7.5},                            },
]
  • Parce que toutes les pages sont mises en cache, l'idée de base est [Quand le cache sera-t-il détruit ? ]. Ma conception est la suivante : le cache de la page actuelle sera conservé lors du passage à la page suivante au même niveau, et [le cache de la page actuelle sera détruit lors du retour à la page précédente].
  • Ainsi, dans main.js, j'ai utilisé la méthode Vue.mixin pour intercepter l'événement de sortie de route et implémenté la fonction de destruction du cache de page dans la méthode d'interception. Le code de base est le suivant :
Vue.mixin({
    beforeRouteLeave:function(to, from, next){
        if (from && from.meta.rank && to.meta.rank && from.meta.rank>to.meta.rank)
        {//如果返回上一层,则摧毁本层缓存。
            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 = this.$vnode.key == null
                                    ? 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];
                        }
                    }
                }
            }
            this.$destroy();
        }
        next();
    },
});

Résumé : En fait, via le composant keepAlive de niveau supérieur où se trouve le composant de page, la liste de cache dans l'objet est violemment manipulée. . .

Simple et direct, bien que pas très élégant, il est facile à utiliser, haha ​​:)

Bien sûr, j'espère toujours que l'API de support officielle sortira mieux.

Mais de cette façon, la mémoire ne sera pas libérée. Je désactive keepalive et tout ira bien. L'ajout de keepalive puis la suppression manuelle du cache et la destruction de la mémoire augmentent toujours. Je me demande si vous avez fait attention à cet aspect ?

@Liudapeng Je n'ai pas étudié attentivement l'utilisation de la mémoire auparavant. J'ai fait un test approximatif et je ne l'ai pas étudié attentivement après avoir vu la mémoire chuter dans la chronologie du graphique de la mémoire.

Je suis un peu occupé ces derniers temps, j'ai vu votre message il y a deux jours et je n'ai pas eu le temps de vous répondre.

Je viens de refaire un test, répété plusieurs fois pour approfondir les cinq ou six niveaux de la page puis revenir à la page d'accueil.Les résultats de la chronologie mémoire sont les suivants :

  • Activez keep-alive et détruisez dynamiquement le composant (c'est-à-dire utilisez la méthode que j'ai mentionnée ci-dessus):
    > Vous pouvez clairement voir la chute de mémoire dans la timeline. Je pense que la mémoire est détruite.
    snipaste_2018-09-29_17-53-09

N'utilisez pas keep-alive :

Parce qu'il n'y a pas de keepalive, la pile mémoire ne sera pas très rapide, mais elle devient de plus en plus élevée (peut-être que mon code est modifié à la va-vite, et qu'il y a des fuites de mémoire ailleurs)
snipaste_2018-09-29_17-50-40

Mais en général, je pense qu'après avoir utilisé la destruction dynamique, l'utilisation de la mémoire est toujours dans la plage acceptable, donc si vous rencontrez une augmentation significative de la mémoire, vous devez vérifier si l'événement de liaison n'est pas détruit lorsque le composant est détruit (causant bien que le composant est supprimé du tableau de cache de keepAlive, il n'est pas détruit de la mémoire).

Veuillez vérifier à nouveau.

@wanyaxing j'ai le même problème dans mon projet,sans keep-alive:
image
Appeler le $destory () du composant dynamique ne fonctionne pas et je trouve que les tas JS augmentent avec le nombre de nœuds. Il semble que le composant dynamique ait créé des DOM sans les détruire.

@bigggge name est l'attribut à l'intérieur du composant, pas l'attribut de la route

Ma question est encore plus bizarre. Ma version de vue est la 2.3.3. La page A a un code pour faire défiler pour charger la page suivante. Je suis passé de la page A à la page B. Lorsque la page B défilait, j'ai trouvé que le code de la page A pour charger la page suivante encore être exécuté. Lorsque je supprime le keep-alive global, le problème ci-dessus ne se produira pas. Mais tous mes activés sont à nouveau invalides, je dois utiliser created.

Ma question est encore plus bizarre. Ma version de vue est la 2.3.3. La page A a un code pour faire défiler pour charger la page suivante. Je suis passé de la page A à la page B. Lorsque la page B défilait, j'ai trouvé que le code de la page A pour charger la page suivante encore être exécuté. Lorsque je supprime le keep-alive global, le problème ci-dessus ne se produira pas. Mais tous mes activés sont à nouveau invalides, je dois utiliser created.

Cela peut être causé par une surveillance globale, vous pouvez juger s'il s'agit de la route actuelle lors du défilement, puis décider de charger la page suivante

Ma question est encore plus bizarre. Ma version de vue est la 2.3.3. La page A a un code pour faire défiler pour charger la page suivante. Je suis passé de la page A à la page B. Lorsque la page B défilait, j'ai trouvé que le code de la page A pour charger la page suivante encore être exécuté. Lorsque je supprime le keep-alive global, le problème ci-dessus ne se produira pas. Mais tous mes activés sont à nouveau invalides, je dois utiliser created.

Cela peut être causé par une surveillance globale, vous pouvez juger s'il s'agit de la route actuelle lors du défilement, puis décider de charger la page suivante

Oui, j'utilise le plug-in vue-infinite-scroll. Lorsque j'utilise le keep-alive global, cela ne supprime pas l'événement de surveillance. J'ai réécrit ce plug-in.

J'ai utilisé le script de @wanyaxing pour réaliser la fonction d'effacement du cache, et avec la file d'attente des sauts d'enregistrements, il est plus facile de gérer l'exigence de restauration et non d'actualisation.Le script est organisé et mis sur l'essentiel
https://gist.github.com/lingceng/c204bac2704d03db99932d5457e662e6

@jkzing Et si je charge deux fois le même composant, l'un doit être mis en cache et l'autre n'a pas besoin d'être mis en cache ? Leurs noms de composants sont les mêmes.

J'ai également cette question. Include ne peut pas répondre à cette exigence. Si plusieurs pages de routage correspondent à un composant, il n'y a qu'un seul nom de composant. Que dois-je faire ?

Lorsque l'onglet est basculé, le cache est fermé et le cache est détruit et la prochaine fois qu'il est ouvert et rechargé avec plusieurs pages de sous-routage imbriquées, la même chose est vraie.

@ heng1234Bonjour, avez-vous résolu ce problème ? Qui peut laisser une information de contact pour obtenir des conseils ?

Ne changez pas de page par routage et par composants
https://blog.csdn.net/qq_39313596/article/details/82628953

[email protected]

De : Codezéro123
Heure d'envoi: 2019-12-03 10:04
Destinataire : vuejs/vue
Cc : hlvy ; Mentionner
Objet : Re : [vuejs/vue] J'espère que keep-alive peut augmenter la fonction de suppression dynamique des composants mis en cache (#6509)
Lorsque l'onglet est basculé, le cache est fermé et le cache est détruit et la prochaine fois qu'il est ouvert et rechargé avec plusieurs pages de sous-routage imbriquées, la même chose est vraie.
@ heng1234Bonjour, avez-vous résolu ce
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désabonnez-vous.

@wanyaxing vous n'êtes pas efficace pour le cache de routage à trois
routage.
{ path: '/nested', component: Layout, redirect: '/nested/menu1/menu1-1', name: 'Nested', meta: { title: 'Nested Routes', icon: 'nested' }, children: [ { path: 'menu1', component: () => import('@/views/nested/menu1/index'), // Parent router-view name: 'Menu1', meta: { title: 'Menu 1' }, redirect: '/nested/menu1/menu1-1', children: [ { path: 'menu1-0', component: () => import('@/views/nested/menu1/menu1-0'), name: 'Menu1-0', meta: { title: 'Menu 1-0', noCache: true } }, { path: 'menu1-1', component: () => import('@/views/nested/menu1/menu1-1'), name: 'Menu1-1', meta: { title: 'Menu 1-1' } }, { path: 'menu1-2', component: () => import('@/views/nested/menu1/menu1-2'), name: 'Menu1-2', redirect: '/nested/menu1/menu1-2/menu1-2-1', meta: { title: 'Menu 1-2' }, children: [ { path: 'menu1-2-1', component: () => import('@/views/nested/menu1/menu1-2/menu1-2-1'), name: 'Menu1-2-1', meta: { title: 'Menu 1-2-1' } }, { path: 'menu1-2-2', component: () => import('@/views/nested/menu1/menu1-2/menu1-2-2'), name: 'Menu1-2-2', meta: { title: 'Menu 1-2-2' } } ] }, { path: 'menu1-3', component: () => import('@/views/nested/menu1/menu1-3'), name: 'Menu1-3', meta: { title: 'Menu 1-3' } } ] } ] }

`Vue.mixin({
beforeR outeLeave:function (to, from, next){
if (de.meta.noCache) {
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 = this.$vnode.key == null
          ? 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];
        }
      }
    }
    this.$destroy();
  }
}
next();

},
});`

L'idée est ce genre d'idée. Il n'y a pas de problème avec l'idée. Quand appeler et détruire le cache, cela dépend de l'implémentation spécifique dans votre entreprise.

Ce genre de scénario de notre côté commercial devrait être très scénario :
1. J'ai parcouru plusieurs pages et j'ai besoin d'être mis en cache
2. Cliquez pour quitter, vous devez effacer tout le cache
3. Il y a d'autres invites de redirection d'erreur après la connexion, ces pages ne sont pas mises en cache
4. La connexion est réussie et la nouvelle page continue d'être mise en cache

Maintenant, j'ai trouvé qu'il était impossible d'effacer tous les caches lorsqu'il atteignait 2. Mettre la valeur maximale de keep-alive dans vuex et la définir sur 1 n'est toujours pas valide, selon les outils de développement de vue, il y a toujours des pages en cache.
Ce qui m'est encore plus étrange, c'est que sauter vers d'autres pages sans connexion en 3 déclenchera le montage de la page en cache en 1, et en regardant les outils de développement, ces pages sont toutes inactives. Hé, cela conduit à une logique de page différente. de problème.
Après avoir cherché longtemps, je ne sais toujours pas pourquoi

Ce genre de scénario de notre côté commercial devrait être très scénario :
1. J'ai parcouru plusieurs pages et j'ai besoin d'être mis en cache
2. Cliquez pour quitter, vous devez effacer tout le cache
3. Il y a d'autres invites de redirection d'erreur après la connexion, ces pages ne sont pas mises en cache
4. La connexion est réussie et la nouvelle page continue d'être mise en cache

Maintenant, j'ai trouvé qu'il était impossible d'effacer tous les caches lorsqu'il atteignait 2. Mettre la valeur maximale de keep-alive dans vuex et la définir sur 1 n'est toujours pas valide, selon les outils de développement de vue, il y a toujours des pages en cache.
Ce qui m'est encore plus étrange, c'est que sauter vers d'autres pages sans connexion en 3 déclenchera le montage de la page en cache en 1, et en regardant les outils de développement, ces pages sont toutes inactives. Hé, cela conduit à une logique de page différente. de problème.
Après avoir cherché longtemps, je ne sais toujours pas pourquoi

Dans votre scénario, au moment de 2, vous devriez envisager d'actualiser la page directement, ce qui est la solution la plus sûre et la plus directe.

Parce qu'include correspond au nom du composant, que se passe-t-il si plusieurs routes correspondent à un seul composant ? Existe-t-il un moyen de donner un nom différent au même composant ?

Cette page vous a été utile?
0 / 5 - 0 notes