Quale è il migliore pushstate o location.hash?

window.location.hash vs HTML5 history.pushstate . Quale di questi sarebbe meglio incontrare l’url con la richiesta Ajax e perché? Grazie.

location.hash ha un supporto migliore rispetto al metodo history.pushState .
Il vantaggio del metodo pushState è che è ansible associare uno stato alla voce della cronologia.
Se non hai bisogno di questo object stato, ti consiglio di usare la proprietà location.hash , per avere una migliore compatibilità con i browser più vecchi.

 location.hash = 'new-hash'; console.log(history.state); // null or undefined history.pushState({extraData: "some state info"}, '', 'new-hash'); //<--- console.log(history.state); // [object Object] = {"extraData": "some state info"} 

Pushstate è il futuro. È meglio perché:

  1. Sembra più pulito
  2. Sulla rivisitazione di un link diretto puoi effettivamente visualizzare dati reali sul server per supportare cose come SEO e Facebook Open Graph (entrambi inviano gli spider a grattare l’html della tua pagina).
  3. I server non hanno accesso ai dati dei tag hash, quindi non li vedi nei registri del server, quindi sono utili per l’analisi.
  4. Aiuta a risolvere i problemi dei tag hash. Ad esempio, ho avuto una riscrittura Nginx per redirect gli utenti che visitano la mia app allo stesso URL https. Funziona in tutti i browser, ma Safari che ti reindirizza al dominio senza l’hash (così fastidioso)!
  5. In realtà puoi usare il tag hash per ciò che è stato pensato, il collegamento profondo a sezioni di pagine lunghe.
  6. Puoi ricorrere all’utilizzo di richieste di back-end HTTP per browser che non supportano lo stato push O puoi ricorrere all’utilizzo del tag hash. Entrambi richiedono un’implementazione extra, ma sono facilmente realizzabili con un po ‘di lavoro.

Vedi questo talk di Github designer per ulteriori informazioni : http://warpspire.com/talks/responsive/

history.pushState è migliore di location.hash . ma è una funzionalità HTML5. quindi sempre meglio avere un metodo di fallback come di seguito.

 if (typeof(window.history.pushState) == 'function') { window.history.pushState(null, path, path); } else { window.location.hash = '#!' + path; } 

Sono d’accordo con le altre risposte, ma qui ci sono alcuni argomenti a favore di location.hash :

  • funziona in tutti i browser, incluso Internet Exploder TM
  • history.pushState è uno standard di sviluppo e l’API potrebbe cambiare in futuro
  • se gli utenti aprono un collegamento in una nuova finestra / scheda, un hash-URL assicura che non vi sia alcuna richiesta server per caricare la pagina (se sono state impostate le intestazioni di cache corrette)
  • La configurazione del server è semplice, dal momento che tutto ciò che il server vede è l’URL senza hash-part

modifica: ne ho dimenticato uno

  • con gli hashtag, puoi usare i link reali ( a href ). Quindi non è necessario impostare listener di clic, che migliora le prestazioni e riduce le dimensioni del codice.

I vantaggi / svantaggi di window.location.hash rispetto a HTML5 history.pushstate sono in gran parte determinati dal modo in cui si desidera che la pagina si degradi.

Qui, potresti essere interessato a un gradevole degrado in due diversi scenari:

Il primo è un client che non ha javascript abilitato o un bot / crawler automatico che visita il tuo sito. Questo è particolarmente importante da una prospettiva SEO. Se la tua pagina web / applicazione web utilizza hash-url, il contenuto disponibile tramite questi collegamenti non è disponibile per questi utenti finali. Questo è sicuramente un problema se si stanno rendendo disponibili sezioni di contenuto solo tramite hash-urls senza fallback. Tuttavia non è sicuramente un problema se si utilizzano i collegamenti hash-tag per modificare lo stato dell’applicazione che semplicemente non mantengono il significato se la pagina si deteriora.

Ad esempio, considera uno scenario in cui hai una pagina con tre sezioni di testo disponibili in tre tabs in un widget di layout a tabs. Ora ci sono due possibili scenari: nel primo, caricheresti tutto il contenuto durante il caricamento della pagina – e il widget a tabs servirà semplicemente per hide altre sezioni e mostrare una sezione particolare. Quindi se usi hash-urls nei link che usi per build i thumbs della scheda, li stai usando solo per cambiare lo stato dell’applicazione lato client. Quando javascript è distriggersto / non è disponibile, semplicemente il javascript utilizzato per build il layout a tabs non viene eseguito e tutto il contenuto è immediatamente disponibile, con un ragionevole ritorno di sicurezza. I diversi stati dell’applicazione semplicemente non esistono in questo caso e quindi gli hash-urls si degradano semplicemente puntando ad ancore in html – lo scopo previsto. Invece di hash-urls, se dovessi usare html5 pushstate in questo caso, sarebbe una ctriggers idea. Il motivo è che un utente possa aggiungere il link a una determinata scheda. Perché il tuo server dovrebbe prendere quell’URL e presentare all’utente lo stato lato client che si aspetta. Questo non va bene per un’architettura thin server in cui il lato client dovrebbe prendersi cura della propria gestione dello stato. Ovviamente puoi ignorare questo aspetto dal lato server e lasciare che il client controlli l’url proprio all’inizio del caricamento della pagina e poi passi allo stato appropriato dell’applicazione. Ma ancora non è una buona idea perché il vostro sistema di routing lato server si occupa del sovraccarico di ulteriori frammenti di URL che dovrebbe ignorare, dove come non dovrebbe essere preoccupato di quel frammento affatto da una prospettiva estetica. Questo programma si conforma esattamente al requisito per il quale sono stati progettati hash-URL e si consiglia vivamente di utilizzarli. Se invece nelle tre sezioni, il testo viene caricato dynamicmente quando si fa clic su una determinata scheda, quindi utilizzare hash-urls non è una buona idea. Il motivo è che l’utente non avrà semplicemente modo di accedere al contenuto collegato se javascript non è disponibile. Questo è particolarmente negativo per il SEO. In questo scenario, se gestisci gli url (che nel normale scenario sarebbero “dirottati” e “ajaxificati”) sul lato server per rendere il contenuto disponibile in generale, è eccellente sia dal punto di vista dell’esperienza dell’utente finale che del SEO.

Il secondo scenario è un client che ha un browser antiquato che non supporta i pushstate html5. Anche se i punti di cui sopra continuano a valere, in aggiunta vorrei anche affermare che forzare gli utenti senza stato di pushstate con lo stesso livello di degrado di quanto non sia giustificato nessun javascript. Un sacco di utenti finali non avranno semplicemente idea del motivo per cui stanno ricevendo una versione degradata.

Ti consiglio di non associarti alla motivazione dogmatica di utilizzare sempre la tecnologia più recente e di decidere l’opzione migliore per il tuo scenario di utilizzo.

Personalmente preferisco pushState perché rende gli URL più belli e penso che sia importante per l’esperienza dell’utente.

È ansible utilizzare history.pushState con un fallback hash utilizzando il polyfill history.js se si desidera utilizzare pushState, ma non si desidera avere problemi con il supporto del browser precedente.

Attualmente, pushState è supportato da tutti i browser moderni. Pertanto, pushState è migliore di location.hash , ma è una funzionalità HTML5.

Quindi, location.hash non è morto, infatti sarà in giro per molto, molto tempo.

Un buon modo per usarlo è con una lib che supporta pushState , ma si degrada con grazia anche con l’uso di location.hash .
Esempio : https://github.com/browserstate/history.js

Inoltre, location.hash sarà comunque utile per saltare alle ancore con nome. pushState sarà di grande aiuto nella creazione di app web. Non vedo l’ora di usarlo.

Questa è una domanda piuttosto vecchia (5 anni + al momento di questa risposta) ma molti commenti sulle risposte esistenti richiedono un aggiornamento basato sullo stato “attuale” delle cose.

Ecco l’accordo:

Il pushState di HTML5 è supportato su tutti i principali browser. Se stai supportando anche i browser più vecchi, history.js offre un ottimo polyfill che ti consente di utilizzare pushState in modo nativo e di farlo facilmente tornare agli URL precedenti per i browser più vecchi. Ora che pushState è supportato in modo nativo non significa, tuttavia, che sia definitivamente la strada da percorrere.

C’è un punto molto importante che non è stato sollevato in nessuna delle risposte precedenti e cioè che gli URL hash e gli URL pushState non sono solo diversi nel modo in cui appaiono, ma sono anche diversi nel modo in cui funzionano. Questa differenza fondamentale tra i due potrebbe portarti a scegliere l’uno rispetto all’altro.

pushState è più carino e pulito e può essere utilizzato per falsificare completamente la navigazione sul tuo sito / nella tua app. Ad esempio, GitHub lo usa per sostituire tutta la navigazione in modo invisibile. Quando fai clic su un collegamento sul loro sito, javascript viene utilizzato per intercettare quel clic e trasformarlo in una richiesta AJAX che aggiorna il contenuto della pagina senza caricare una nuova pagina, mentre l’URL nella barra degli indirizzi cambia per adattarsi al contenuto che era inverosimile. Questo è ciò per cui pushState era destinato .

Nel caso di GitHub, http: // mysite / page1 e http: // mysite / page2 sono entrambi URL validi. Sono collegamenti “reali” con contenuti “reali” e inizialmente la visita di entrambe le pagine passa attraverso il tradizionale approccio MVC. GitHub utilizza pushState per la navigazione nei browser moderni, ma non lo richiede, ad esempio pushState viene utilizzato come “aggiunta di funzionalità” (a loro parere) per un’esperienza utente migliore in termini di navigazione. Quando si copia il collegamento nella barra degli indirizzi del browser, si sta copiando un collegamento che è stato formato tramite javascript e pushState, ma un collegamento che è comunque reale e valido.

Tuttavia, se si sta partendo da zero e creando un’applicazione a singola pagina e non si sta utilizzando un framework MVC, è probabile che in realtà si abbia una sola pagina, specialmente se non si utilizza un back-end dinamico (cioè il contenuto viene recuperato tramite javascript , mai generato da un server). In questo caso, se si utilizza pushState su hash URL, sarà necessario gestire il caso in cui l’URL nel browser non sia l’URL reale. Illustrerò.

L’utente carica l’app per singola pagina: http: // mysite / mainpage

A questo punto, la barra del browser contiene il link reale alla tua app e porterà l’utente alla stessa vista che attualmente vede: la pagina principale. Ora fanno clic su un collegamento che li porterà in una “pagina” che mostra i dettagli di alcune attività. A questo punto, si desidera aggiornare la barra della posizione per indicare il cambiamento di stato. O usi un URL di hash e la barra di posizione assomiglia a http: // mysite / mainpage # charts / 1 oppure usi pushState e la ingannerai diventando http: // mysite / mainpage / charts / 1

Se hai utilizzato pushState, questo non è un vero collegamento . La navigazione tramite i pulsanti Indietro / Avanti del browser funzionerà perfettamente e l’utente passerà dalla pagina principale alla pagina dei dettagli sia nella barra della posizione che nell’app (presumendo che tu gestisca correttamente la modifica dello stato), ma se l’utente seleziona questo collegamento oppure copia e incolla il link per condividerlo, sarà richiesto un voodoo lato server aggiuntivo.

Dovrai redirect le richieste a / mainpage / charts / 1 a / mainpage e quindi usare JS per risolvere l’URL effettivo ed eseguire l’operazione di cambio di stato prevista. Un reindirizzamento del server è assolutamente necessario. Non puoi ospitare questa pagina su AWS o sul tuo disco locale senza un server http scriptable.

Ora se hai usato gli hash, l’URL che l’utente avrebbe visto e interagito sarebbe stato http: // mysite / mainpage # / charts / 1 e questo è un url reale e valido . I browser capiscono che c’è solo una pagina e se l’utente copia e incolla il link o lo contrassegna come segnalibro, devi solo gestire lo stato dell’hash in javascript e non serve alcuna magia sul lato server per far funzionare le cose.

Quello che nessuno sembra menzionare è che i link pushState e hash non si escludono a vicenda . pushState è solo un’API per manipolare la posizione del browser che è visibile all’utente e implementare una affidabile navigazione back / forward nei browser moderni. Non dice nulla su come dovrebbe essere il tuo schema URL.

Nel 2017, Google e quasi tutti gli altri bot con funzionalità JS comprendono gli URL hash e li attraversano perfettamente. Google vuole che tu usi il #! abominio per scopi di massimizzazione SEO, ma anche se non lo fai, il tuo sito sarà navigabile bene.

La risposta corretta è quella di utilizzare qualsiasi cosa si adatta meglio alle tue esigenze. Se si dispone di URL reali e si desidera simulare la navigazione tra di essi, utilizzare pushState e proseguire (facoltativamente con un polyfill per i browser meno recenti). Ma se hai un’app a pagina singola, non fingere di non farlo (a meno che tu non abbia una buona ragione). Utilizza gli URL hash per semplificarti la vita e non introdurre problemi non necessari, quindi usa pushState per manipolare tali URL hash per sfruttare il supporto back / forward migliore .