Comment Gmail gère-t-il le back/forward dans un code JavaScript riche?

Question

Gmail semble avoir une façon intelligente de gérer les boutons Précédent/Suivant dans une application JS riche.

Dans mon organisation, nous avons testé le plugin jQuery history. Le plugin exécute une fonction toutes les 100ms qui analyse l'URL et teste si elle a changé. L'historique est suivi par des ancres HTTP, et si l'ancre a changé, le plugin appelle un rappel spécifié par l'utilisateur, en transmettant la nouvelle ancre, afin que la page puisse effectuer un comportement personnalisé à charger dans le nouveau contenu.

Mon organisation a déterminé que le plug-in d'historique jQuery n'était pas de qualité de production. Je ne les blâme pas pour être honnête, parce que vous ne voulez pas vraiment forcer les navigateurs de vos utilisateurs à exécuter une fonction toutes les 100ms. En outre, il rendait le code JS presque impossible à déboguer, car en cliquant sur "Break On Next" dans Firebug ou un débogueur JS similaire, l'événement d'historique jQuery serait toujours piégé, et aucun autre événement n'obtiendrait un aperçu.

abandonné à ce stade sur la mise en œuvre des fonctionnalités back/forward dans le navigateur. Cependant, j'ai récemment remarqué que Gmail l'implémente plutôt bien. Il utilise également la valeur d'ancrage HTTP, mais j'ai appuyé sur "Break On Next" et Gmail n'exécute aucune sorte de fonction toutes les 100ms. Comment Gmail parvient-il à implémenter ce comportement back/forward?

Answer 1

peut-être que vous parlez du plug-in Histoire jQuery ici: http://www.balupton.com/projects/jquery-history qui a été utilisé chez l'homme y des sites de qualité de production; Un de mes favoris est http://wbhomes.com.au/

Si c'est le cas, il utilise un test de 200ms pour older generation browsers qui n'implémente pas l'événement onhashchange en mode natif. Sans cet événement implémenté de manière native, vous devez contourner ses fonctionnalités en utilisant un changement d'intervalle - il n'y a tout simplement pas d'autre moyen à ma connaissance. Heureusement, les dernières versions de tous les principaux navigateurs prennent en charge nativement l'événement onhashchange. Cette vérification n'est donc plus nécessaire.

Mais hélas, voyons ce que fait cette vérification de l'intervalle de 200 ms. S'ils sont sur IE6 ou 7, ils vérifient l'état d'un iframe (comme dans ces navigateurs, un iframe est nécessaire pour émuler les boutons back et forward - où pour les autres navigateurs un iframe n'est pas nécessaire). S'ils utilisent un autre navigateur plus ancien qui n'est pas IE alors il peut simplement utiliser location.getHash() dans la vérification (sans iframe comme expliqué précédemment). Les deux types de chèques sont conçus pour être extrêmement rapides et aussi minimes que possible, réduisant à néant les frais généraux nécessaires. Tout dépend de ce que le navigateur est prêt à vous laisser faire, et essayez de le faire en utilisant le code le moins intensif possible.

Remarque: Avant la version v1.4.2-final (12 août 2010) de jQuery History, les seuls navigateurs reconnus qui supportaient onhashchange de manière native étaient IE8 et supérieur. Cela a été résolu dans toutes les versions plus récentes du projet jQuery History.

Answer 2

Vous pouvez vérifier cette question précédente:

Is there a way to catch the back button event in javascript?

Il semble que la façon dont il est fait dans jQuery est la seule façon de le faire parce que ce YUI fait trop:

http://developer.yahoo.com/yui/history/