Creuser dans l'API d'histoire de HTML5

Cet article présente principalement l'exploration approfondie de l'API d'histoire HTML5 et se concentre sur les nouvelles méthodes History.pushstate () et History.replacestate () dans HTML5. Les amis qui en ont besoin peuvent y faire référence.

L'histoire est amusante, n'est-ce pas? Dans les versions HTML précédentes, nous avons eu des opérations très limitées sur l'historique de navigation. Nous pouvons utiliser les méthodes que nous pouvons utiliser d'avant en arrière, mais c'est tout ce que nous pouvons faire.

Cependant, en utilisant l'API d'histoire HTML 5, nous pouvons mieux contrôler l'historique du navigateur. Par exemple: nous pouvons ajouter un enregistrement à la liste de l'historique ou mettre à jour l'URL de la barre d'adresse lorsqu'il n'est pas actualisé.

Pourquoi introduire une API d'histoire?

Dans cet article, nous découvrirons l'origine de l'API d'histoire dans HTML 5. Avant cela, nous avons souvent utilisé des valeurs de hachage pour modifier le contenu de la page, en particulier ceux qui sont particulièrement importants pour la page. Parce qu'il n'est pas actualisé, il est impossible de modifier son URL pour une seule application de page. De plus, lorsque vous modifiez la valeur de hachage de l'URL, cela n'a aucun effet sur l'histoire du navigateur.

Ensuite, maintenant pour l'API d'historique HTML 5, celles-ci sont faciles à mettre en œuvre, mais comme les applications d'une seule page n'ont pas à utiliser les valeurs de hachage, cela peut nécessiter des scripts de développement supplémentaires. Il nous permet également de créer de nouvelles applications d'une manière conviviale de référencement. De plus, cela peut réduire la bande passante, mais comment peut-il être prouvé?

Dans l'article, j'utiliserai l'API de l'historique pour développer une application à une seule page pour prouver le problème ci-dessus.

Cela signifie également que je dois d'abord charger les ressources nécessaires sur la page d'accueil. À démarrer maintenant, la page ne charge que le contenu dont vous avez besoin. En d'autres termes, l'application ne charge pas tout le contenu au début et ne sera chargée que lors de la demande du deuxième contenu de l'application.

Notez que vous devez effectuer un codage côté serveur pour fournir une partie des ressources, et non le contenu de la page complète.

Lors de la rédaction de cet article, l'API du support de l'histoire des navigateurs majeurs est très bonne. Vous pouvez cliquer ici pour voir leur support. Ce lien vous indiquera les navigateurs pris en charge et avant de les utiliser, il existe toujours de bonnes pratiques pour détecter des fonctions prises en charge spécifiques.

Afin de déterminer si le navigateur prend en charge cette API d'une manière, vous pouvez utiliser la ligne de code suivante pour vérifier: