Analyse de cas de commutation de routage de terminal mobile Vue

Cette fois, je vais vous apporter une analyse du cas du changement de routage mobile vue. Quelles sont les précautions pour le changement de routage mobile vue Voici un cas pratique, jetons un coup d'oeil.

Les plus importants d'entre eux sont les deux problèmes suivants :

Changement de la barre de navigation du navigateur

Lorsque vous faites glisser pour allumer IOS, il y aura deux pages transitions. Animation de champ, un commutateur lorsqu'il glisse, puis déclenche l'animation de transition que nous avons définie.

À l'exception des deux questions ci-dessus, le reste des opérations peut être défini dans la page et est fondamentalement contrôlable. Principalement pour résoudre les deux problèmes ci-dessus.

Vous pouvez voir l'effet écrit réel : DÉMO en ligne

1. Changer la barre de navigation du navigateur

En enregistrant l'historique Pour comparer et juger s'il faut avancer ou reculer

L'exemple suivant

Une page->B page-> 🎜> Si je passe de la page A à la page B puis à la page C, il y aura 3 enregistrements historiques

On utilise un tableau pour représenter : ['/a', '/b', '/c ']

Ensuite, en cliquant sur le bouton Précédent de la barre de navigation du navigateur, je reviendrai à la page B.

À ce stade, il me suffit de déterminer si la page B existe. L'existence le prouve. que j'ai cliqué sur le bouton retour.

Ensuite, une fois que je suis revenu en arrière, je peux cliquer sur le bouton Suivant du navigateur. Comment juger si cela avance à ce moment-là ?

Nous pouvons le faire.

Quand on revient à la page B, l'historique n'a-t-il pas encore les trois chemins ['/a', '/b', '/c']

On peut supprimer ? page B Le chemin suivant est maintenant ['/a', '/b'];

Ce qui précède est une situation normale.

Le problème apparaît à ce moment-là. Nous supprimons la première page B. path consiste toujours à supprimer le chemin derrière la deuxième page B

Essayons d'abord de supprimer le chemin de la deuxième page B, puis les chemins que nous enregistrons encore sont : ['/a', '/b', '/c', '/b'].

1. A ce moment, nous opérons selon la logique de la situation normale ci-dessus

À ce moment, si nous cliquons sur le bouton retour ici, nous irons à la page C, mais le le chemin de sauvegarde est ``/c' ` a été supprimé par moi, donc le jugement est d'aller de l'avant.

1. Serait-il mieux que nous filtrions les chemins de pages en double ? En fait, c'est pareil

Si nous avons 5 chemins de pages, 2 doublons sont filtrés Oui, là il n'y a que des chemins de 3 pages

aléatoire

implémentation du code :

Le code ci-dessus Nous pouvons ajouter une chaîne aléatoire de APP_KEY à l'URL, de sorte que même si la même page se trouve dans le chemin que nous enregistrons, elle sera en réalité différente. La logique peut être exécutée normalement

// 当没有key的时候会进入两次 beforeEach,我们只需保存带key的就行
const updateNavigations = (to) => {
 if (to.query[pathKey]) {
  store.commit('UPDATE_NAVIGATIONS', {path: to.fullPath})
 }
}

router.beforeEach((to, from, next) => {
 let toIndex = store.state.navigations.findIndex(path => path === to.fullPath)
 if (toIndex >= 0) { // 存在该路径
  let len = store.state.navigations.length-1
  if (toIndex === len) { // 当前路径是最后一条，证明是同一个页面
   console.log('refresh') 
  } else { // 后退
   store.commit('UPDATE_ROUTER_DIRECTION', { routerDirection: 'back' }) // 后退标志
   store.commit('DELETE_NAVIGATION', { index: toIndex }) // 删除当前路径后面的路径
  }
 }else{ // 不存在该路径
  store.commit('UPDATE_ROUTER_DIRECTION', { routerDirection: 'forward' }) // 前进标志
  updateNavigations(to) // 保存该连接
 }

 const query = { ...to.query }
 // 存在就直接next， 防止死循环
 if (!query['APP_KEY']) { // 不存在添加key ，再次 next
  query['APP_KEY'] = Math.random().toString(16).substring(2)
  next({ path: to.path, query})
 }else{
  next()
 }
})

Sur la page Web IOS, vous pouvez glisser vers la gauche et la droite pour basculer, même si vous ne faites pas d'animation de transition.

Un problème va surgir à ce moment.
Page ABC fixe

A -> B -> terminer le glissement Il entrera dans la page B, mais à ce moment-là, il entrera toujours dans notre fonction de hook beforeEach et exécutera notre logique ci-dessus.

Le code est comme ça

Ce qui précède est également facile à comprendre, c'est-à-dire que nous obtenons le moment où le doigt quitte finalement l'écran, puis le comparons avantEach
Le dernier moment où le doigt quitte l'écran est différent de la transition. nous avons fait avantChacun Moins de 337, même la commutation coulissante d'IOS

résoudra le problème de commutation coulissante d'IOS.

Cependant, le moment où le doigt quitte l'écran ne peut pas être surveillé lors du glissement vers la droite pour basculer dans IOS (je ne sais pas ce qu'est le fantôme), donc le basculement coulissant vers la droite dans IOS ne peut pas être jugé comme ci-dessus .

Je n’ai pas non plus trouvé de solution à ce problème. Pour le moment, je ne peux résoudre que le problème du balayage vers la gauche pour revenir dans IOS.

Fondamentalement, les deux points les plus gênants sont les deux points ci-dessus. Le reste peut être réglé en surveillant l' événement , ce qui n'est pas difficile du tout

DÉMO en ligne

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Explication détaillée de la façon d'utiliser le sélecteur de nom de classe jQuery (.class)

Composant de liaison dynamique Vue enfant et composants parents Explication détaillée des étapes de mise en œuvre de la vérification multiforme

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!