Sarebbe onpushstate essere un anti-modello?

1

Nelle applicazioni per pagina singola, è normale aggiornare l'URL durante la navigazione e eseguire nuovamente il rendering in base al nuovo URL. Ciò può accadere quando l'utente colpisce il pulsante Indietro e Avanti , fa clic su un anchor tag, o fa qualcosa che spinge un nuovo stato sull'oggetto della cronologia .

Il consenso per rilevare qualsiasi tipo di cambio di URL è comunque per sondaggio ogni millisecondo. Sembra che questo sia dovuto al fatto che mentre gli utenti possono aggiungere un EventListener a popstate e hashchange , non possiamo ancora ascoltare pushstate .

Se esiste un evento onpopstate (utilizzato per la navigazione con pulsante Indietro e Avanti), perché non esiste un evento onpushstate ?

Se onpopstate esiste da così tanto tempo e non ci sono prove di un onpushstate nelle opere, immagino sia stata una decisione consapevole. Ciò significa che l'aggiunta di questo imporrebbe una cattiva programmazione o modelli?

    
posta JRJurman 29.06.2017 - 00:53
fonte

1 risposta

1

Ecco la logica:

Under normal circumstances, if you start at page A, pushstate to page B, refresh, and go back to A, we don't change the document -- the document you got from refreshing B gets a popstate. But if you get a response code of 400 or greater when refreshing B, we consider it to be a different document. If the refresh of B returned, for instance, a 404, then we'd actually load A's document when we go back.

If you're at A, push/replace state to B, and then navigate to C (by setting document.location, clicking a link, etc), we send B as the HTTP referer. But if you're at A, navigate to B, pushstate to C, pushstate to D, then refresh D, we send B as the HTTP referer, because pushstates aren't really navigations.

Riferimenti

risposta data 18.08.2018 - 01:31
fonte

Leggi altre domande sui tag