Het is verbazingwekkend, ik zie dit constant werken op andere sites, maar nooit op sites waar ik aan werk.
Ik breng nieuwe inhoud binnen met ajax, ik weet van history.js en de History API, ik wil de URL niet veranderen, alleen de browser de nieuwe HTML-inhoud in de cache laten plaatsen, zodat wanneer een gebruiker de pagina verlaat en komt terug met de terug-knop, het heeft nog steeds de bijgewerkte HTML.
Ik zie dit altijd werken op andere sites zonder URL-wijzigingen of het gebruik van de hash #.
Is er een truc om het werkend te krijgen of wordt dit willekeurig bepaald door de browser?
Als ik de URL niet wil gebruiken om deze informatie te hebben, is er dan een eenvoudig alternatief?
Antwoord 1, autoriteit 100%
Sinds ongeveer anderhalf decennium gebruik ik twee trucs die ik ooit heb ontdekt met pijnlijk vallen en opstaan: invoerveldwaarden – vooral ‘verborgen’ – worden bewaard in de geschiedenis van de browser, samen met de URL – AND – de gebeurtenis onLoad wordt aangeroepen bij het terugkeren naar de pagina met de knoppen terug (of vooruit).
Dit betekent dat u zoveel ‘state’ kunt opslaan als u wilt – in verborgen velden (vergeet niet om ze in een formulier te plaatsen), en vervolgens de wijzigingen op ‘onLoad’ opnieuw uit te voeren. Meestal maak ik van het ‘render’-gedeelte een aparte functie… Met andere woorden, op het moment dat de dynamiek optreedt, schrijf ik eerst naar de verborgen velden – en roep dan de renderfunctie aan. Vervolgens verzamel ik alle verschillende renderfuncties voor de verschillende stukjes dynamiek en roep ik ze op vanuit de onLoad.
Ik wil benadrukken dat ik hier nooit naar op zoek ben gegaan in handleidingen – dus ik kan geen garanties bieden – maar ik gebruik het al een hele tijd betrouwbaar (sinds Netscape!!!) Het werkt met ‘veel’ browsers ( alle IE’s, chrome, FF – maar wat de anderen betreft, ik heb het nog nooit geprobeerd.)
Als iemand een meer ‘juiste’ – en minder vervelende – manier heeft, dan hoor ik dat graag. Maar dit lijkt de truc te doen.
Antwoord 2, autoriteit 21%
Auteur van RES hier, vond uw vraag in /r/javascript
Blijkbaar heeft Firefox onlangs functionaliteit toegevoegd om dit zelf te doen, maar er is geen “goede” manier om dit te doen als de browser het niet voor u doet.
Wat RES vroeger deed, was een #page=n marker toevoegen waarbij n je paginanummer was. Op die manier weet RES bij het laden van de pagina dat je van de terugknop moet zijn gekomen als er al een location.hash is — helaas veroorzaakte dit specifieke gedrag ctrl-f find in zowel Firefox als Chrome toen een vondst ervoor zorgde dat je naar scrolde een andere pagina (pagina = n+1), omdat een hashwijziging het zoekvenster zou sluiten dat gebruikers irriteerde…
Dus nu doet RES wat lelijke en onvolmaakte gymnastiek om te raden of je al dan niet op de pagina bent gekomen via de terugknop. Elke keer dat het een nieuwe pagina laadt, slaat het dat nummer op in sessionStorage (zoals localStorage, maar lokaal op het tabblad), en wanneer het verschijnt via de terug-knop, start het een verzoek om dat paginanummer.
Echter: onlangs heb ik getest in FF en Chrome en het lijkt erop dat hash-wijzigingen het ctrl-f zoekvenster niet langer “annuleren”, dus mijn suggestie zou zijn dat u dat gebruikt. Bij het laden van een pagina, als er een hash aanwezig is, laadt u de relevante gegevens die door die hash zijn bepaald.
Je kunt, als je echt gek wilt worden, de daadwerkelijke HTML-inhoud opslaan in localStorage en deze ook opnieuw laden bij het laden van de pagina via de terug-knop. Dit is misschien niet de meest efficiënte manier om dingen te doen, en zou vrijwel zeker conflicten veroorzaken met javascript dat afhankelijk is van de DOM, dus wees voorzichtig!
De “beste” oplossing hangt echt af van wat uw site precies doet / hoe die inhoud eruitziet / zich gedraagt.
Antwoord 3, autoriteit 2%
U kunt uw doel als volgt bereiken met History.js:
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
});
Volgens documentatie over Geschiedenis op de Mozilla-site is de derde parameter van PushState:
URL — ……. Deze parameter is optioneel; als het niet is opgegeven, wordt het ingesteld op de huidige URL van het document.
Antwoord 4
Ik denk dat die reden kan zijn dat andere webpagina’s enkele back-endservers gebruiken die sessies bieden.
Als u een statische html/js-pagina aan het bouwen bent, is er geen dergelijke sessie en wordt de pagina alleen opnieuw geladen.
U kunt cookies gebruiken om te bereiken wat u wilt.
Antwoord 5
Lokale opslag is een manier, een andere manier is persistentie aan de serverzijde.
Als de HTML wordt bewerkt/gemaakt/een eigenschap wordt gewijzigd aan de clientzijde, moet u de statuswijziging van uw pagina synchroniseren met webstorage of een database via een rustgevende api (of iets vergelijkbaars).
Als u terugkeert naar de pagina, kan de pagina opgeslagen informatie ophalen uit de lokale opslag… Als u persistentie aan de serverzijde gebruikt, moet u deze gebruiken in combinatie met een sessiecookie om de status van de gebruiker op te halen wijzigingen – die vervolgens van de server kunnen worden geladen.