web-dev-qa-db-fra.com

Préserver le code HTML modifié dynamiquement sur le bouton de retour

C'est incroyable, je vois constamment cela fonctionner sur d'autres sites mais jamais sur les sites sur lesquels je travaille.

J'apporte du nouveau contenu avec ajax, je connais history.js et l'API History, je ne veux pas changer l'URL, il suffit que le navigateur mette en cache le nouveau contenu HTML donc quand un utilisateur quitte la page et revient en utilisant le bouton de retour, il a toujours le HTML mis à jour.

Je vois que cela fonctionne tout le temps sur d'autres sites sans changement d'URL ou en utilisant le hachage #.
Y a-t-il une astuce pour le faire fonctionner ou est-il décidé au hasard par le navigateur?
Si je ne veux pas utiliser l'URL pour obtenir ces informations, existe-t-il une alternative simple?

htmlajaxfirefoxbrowser-historyhistory.js
47
Madd0g

Depuis environ une décennie et demie, j'utilise deux astuces que j'ai découvert par des essais et des erreurs douloureuses: les valeurs des champs de saisie - en particulier celles "cachées" - sont conservées dans l'historique du navigateur avec l'URL - ET - l'événement onLoad est appelé lors du retour à la page par les boutons Précédent (ou Suivant).

Cela signifie que vous pouvez stocker autant d '"états" que vous le souhaitez - dans des champs cachés (n'oubliez pas de les mettre dans un formulaire), puis "refaire" les modifications sur "onLoad". Je fais généralement de la partie 'render' une fonction séparée ... En d'autres termes, au moment où la dynamique se produit, j'écris d'abord dans les champs cachés - puis j'appelle la fonction de rendu. Ensuite, je rassemble toutes les différentes fonctions de rendu pour les différents bits de dynamique et je les appelle depuis onLoad.

Je voudrais souligner que je ne suis jamais allé à la recherche de cela dans aucun manuel - je ne peux donc offrir aucune assurance - mais je l'utilise de manière fiable depuis un bon moment (depuis Netscape !!!) Il fonctionne avec de nombreux navigateurs (tous les IE , chrome, FF - mais comme pour les autres, je n'ai jamais essayé.)

Si quelqu'un a une manière plus "correcte" - et moins fastidieuse -, pour ma part, je serai très heureux d'en entendre parler. Mais cela semble faire l'affaire.

41
Groover

Auteur de RES ici, trouvez votre question dans/r/javascript

Apparemment, Firefox a récemment ajouté des fonctionnalités pour le faire seul, mais il n'y a pas de "bon" moyen de le faire lorsque le navigateur ne le fait pas pour vous.

Ce que RES faisait auparavant était d'ajouter un marqueur # page = n où n était votre numéro de page. De cette façon, sur pageload, RES sait que vous devez provenir du bouton de retour s'il y a déjà un emplacement.hash - malheureusement, ce comportement particulier a falsifié la recherche ctrl-f dans Firefox et Chrome = lorsqu'une recherche vous a fait défiler vers une autre page (page = n + 1), car un hachage changerait la boîte de dialogue de recherche qui agaçait les utilisateurs ...

Alors maintenant, RES fait de la gymnastique laide et imparfaite pour deviner si vous êtes arrivé à la page via le bouton de retour. Chaque fois qu'il charge une nouvelle page, il enregistre ce numéro dans sessionStorage (comme localStorage, mais local dans l'onglet), et lorsqu'il apparaît via le bouton de retour, il déclenche une demande pour ce numéro de page.

Cependant: récemment, j'ai testé dans FF et Chrome et il semble que les modifications de hachage n'annulent plus la boîte de dialogue de recherche ctrl-f, donc ma suggestion serait que vous l'utilisiez. Sur pageload, si il y a un hachage présent, chargez les données pertinentes déterminées par ce hachage.

Vous pouvez, si vous voulez devenir vraiment fou, stocker le contenu HTML réel dans localStorage et le recharger sur pageload via le bouton de retour également. Ce n'est peut-être pas la façon la plus efficace de faire les choses, et cela provoquerait presque certainement des conflits avec le javascript qui repose sur le DOM, alors soyez prudent!

La "meilleure" solution dépend vraiment de ce que fait exactement votre site/à quoi ressemble/se comporte ce contenu.

9
honestbleeps

Vous pouvez atteindre votre objectif en utilisant History.js comme ceci:

function manageHistory(data){

    var History = window.History;
    if ( !History.enabled ) { return false; }        
    History.replaceState({myData: data}, null);
}

$('select.select').change(function(e) { // I am using select tag here to give an example of an HTML action triggerer

    e.preventDefault(); 

    // get data from your select tag

    manageHistory( data)


});

History.Adapter.bind(window, 'statechange', function() { 
    var State = History.getState();

    // Launch the ajax call and update DOM using State.data.myData
});

Selon la documentation sur l'historique sur le site Mozilla, le troisième paramètre PushState est:

URL - ....... Ce paramètre est facultatif; s'il n'est pas spécifié, il est défini sur l'URL actuelle du document.

1
Adib Aroui

Je pense que cette raison peut être que d'autres pages Web utilisent des serveurs principaux qui fournissent une session.

Si vous créez une page html/js statique, il n'y a pas de session et la page se recharge simplement.

Vous pouvez utiliser des cookies pour réaliser ce que vous voulez.

0
el vis

Le stockage local est une façon, une autre est la persistance côté serveur.

Lorsque le code HTML est modifié/créé/une propriété est modifiée du côté client, vous devez synchroniser le changement d'état de votre page avec le stockage Web ou une base de données via une api reposante (ou quelque chose de comparable).

Lorsque vous revenez à la page - la page peut récupérer des informations stockées à partir du stockage local ... Si vous utilisez la persistance côté serveur, vous devrez l'utiliser en conjonction avec un cookie de session pour récupérer les changements d'état de l'utilisateur - qui peut ensuite être chargé à partir du serveur.

0
1nfiniti