Differenza tra window.location.href = window.location.href e window.location.reload ()

196

Qual è la differenza tra JavaScript

window.location.href = window.location.href

e

window.location.reload()

funzioni?

javascript

— Brian
fonte

247

Se ricordo bene, window.location.reload()ricarica la pagina corrente con i dati POST, mentre window.location.href=window.location.hrefnon include i dati POST.

Come notato da @ W3Max nei commenti qui sotto, window.location.href=window.location.hrefnon ricaricherà la pagina se c'è un ancoraggio (#) nell'URL - Devi usarewindow.location.reload() . In questo caso .

Inoltre, come notato da @Mic di seguito, window.location.reload()prende un argomento aggiuntivo in skipCachemodo che con l'utilizzo window.location.reload(true)del browser salti la cache e ricarichi la pagina dal server. window.location.reload(false)farà il contrario e, se possibile, caricherà la pagina dalla cache.

— David Johnstone
fonte

11

tieni presente che quando usi window.location.reload () su un POST il browser ti chiederà se desideri inviare nuovamente i dati per ricaricare la pagina

— con

3

@Wimmel, c'è un modo per disabilitare questo messaggio?

— Kris-I,

40

window.location.href = window.location.href non ricaricherà la pagina se c'è un ancoraggio (#) nell'URL - In questo caso è necessario utilizzare window.location.reload ().

— W3Max,

5

Nota anche che location.reload () forzerà anche il ricaricamento di tutto il contenuto statico (molto simile a un aggiornamento rapido in stile ctrl + f5) mentre l'impostazione di location.href torna a href (o nome percorso o URL) no, il che potrebbe essere significativo (e non necessaria) differenza nel tempo di caricamento in alcune pagine.

— Rob Van Dam

2

@Wimmel Chrome: ricarica la pagina con un GET Firefox: riesegue la richiesta precedente, ovvero se era un POST, otterrai un bel popup che ti chiederà se inviare nuovamente i dati o meno

— Juri,

51

Se dici che window.location.reload(true)il browser salterà la cache e ricaricherà la pagina dal server.window.location.reload(false)farà il contrario.

Nota: defaultvalore per window.location.reload()èfalse

— Mic
fonte

5

@Ismail: l'impostazione predefinita è falsa.

— Trevor

2

Google Chrome 32, durante l'utilizzo di webRTC il vero / falso non ha funzionato per me. Ho avuto un iframe con webRTC e solo usando ha window.location.href = window.location.hreffatto il trucco.

Se sono state apportate modifiche a un modulo nella pagina, le modifiche potrebbero scomparire (ripristinare i valori memorizzati nella cache) a seconda del browser quando si utilizza location.reload()o location.reload(false). Per eseguire un aggiornamento completo della pagina, utilizzare location.reload(true).

— Suncat2000,

32

La differenza è quella

window.location = document.URL;

non ricaricherà la pagina se è presente un hash (#) nell'URL (con o senza qualcosa dopo), mentre

window.location.reload();

ricaricherà la pagina.

— Fabien Ménager
fonte

2

Non tutti i browser hanno questo problema con la fine degli hash. Se gli hash finali sono una preoccupazione per te, prova: window.location = document.URL.replace (/ # $ /, '');

— Walter Stabosz,

1

Almeno Chrome è preoccupato. Ero solito dare location.href = location.hrefper scontato, ma ho appena notato quel comportamento esatto e sono venuto a SO per spargere la voce. Basta usare location.reload()invece.

— Pioul,

1

Puoi anche usare window.location.pathname invece di scrivere una tale espressione regolare. Ad esempio:window.location.replace(window.location.pathname);

— Arseny,

20

Se aggiungi il valore booleano true alla ricarica window.location.reload(true)verrà caricato dal server.

Non è chiaro quanto sia supportato questo booleano, W3Org menziona che NS lo supportava

Ci potrebbe essere una differenza tra il contenuto di window.location.href e document.URL - lì almeno usato per essere una differenza tra location.href e non standard e obsoleto document.location che ha avuto a che fare con il reindirizzamento, ma che è davvero l'ultimo millennio.

A scopo di documentazione, userei window.location.reload () perché è quello che vuoi fare.

— mplungjan
fonte

Guarda stackoverflow.com/a/5091619/429972 poiché questo spiega la differenza.

— incontro

14

Come detto, la modifica dell'href in presenza di un hash (#) nell'URL non ricaricherebbe la pagina. Quindi, lo uso per ricaricarlo invece delle espressioni regolari:

if (!window.location.hash) {
    window.location.href = window.location.href;
} else {
    window.location.reload();
}

— minterior
fonte

6

Sono venuto su questa domanda alla ricerca di alcuni comportamenti aberranti in IE, in particolare IE9, non ha verificato le versioni precedenti. Sembra

window.location.reload();

si traduce in un aggiornamento che oscura l'intero schermo per un secondo, dove as

 window.location = document.URL;

aggiorna la pagina molto più rapidamente, quasi impercettibilmente.

Facendo un po 'più di ricerca e qualche sperimentazione con il violinista, sembra che window.location.reload()bypasserà la cache e ricaricherà dal server indipendentemente dal fatto che passi il booleano con esso o meno, questo include ottenere tutti i tuoi asset (immagini, script, fogli di stile, ecc.) di nuovo. Quindi, se vuoi solo che la pagina aggiorni l'HTML, window.location = document.URLrestituirà molto più rapidamente e con meno traffico.

Una differenza nel comportamento tra i browser è che quando IE9 utilizza il metodo di ricarica, cancella la pagina visibile e sembra che la ricostruisca da zero, dove FF e Chrome aspettano di ottenere i nuovi asset e ricostruirli se diversi.

— invertedSpear
fonte

window.location = document.URL ricarica la pagina proprio come window.location.reload (). Esiste uno stato dell'arte per rinfrescarsi senza scorrere verso l'alto o impercettibilmente come hai detto?

— bigmugcup,

6

Una differenza in Firefox (12.0) è che su una pagina renderizzata da un POST, reload () farà apparire un avviso e farà un nuovo post, mentre un'assegnazione URL farà un GET.

Google Chrome fa un GET per entrambi.

— MRJ
fonte

1

Chrome 38 ora sembra utilizzare POST per .reload ().

— Glen Little,

3

Utilizzando JSF, sto riscontrando il problema con l'aggiornamento dopo la scadenza della sessione: PrimeFaces ViewExpiredException dopo il ricaricamento della pagina e con alcune indagini ho trovato una differenza in FireFox:

La chiamata window.location.reload()funziona come facendo clic sull'icona di aggiornamento su FF, aggiunge la linea

Cache-Control max-age=0

mentre l'impostazione window.location.hreffunziona come premendo INVIO nella riga dell'URL, non invia quella riga.

Sebbene entrambi vengano inviati come GET, il primo (ricaricare) sta ripristinando i dati precedenti e l'applicazione si trova in uno stato incoerente.

— Marinaio Danubiano
fonte

1

No, non ci dovrebbe essere. Tuttavia, è possibile che ci siano differenze in alcuni browser, quindi in entrambi i casi (o nessuno dei due) potrebbe non funzionare.

— Olli
fonte

1

dalla mia esperienza di circa 3 anni, non sono riuscito a trovare alcuna differenza ...

modifica: sì, come ha detto uno di questi, passare solo un parametro booleano a window.location.reload () è la differenza. se passi true , il browser carica una nuova pagina, ma se false , viene caricata la versione della cache ...

— kumarharsh
fonte

0

Nel nostro caso vogliamo solo ricaricare la pagina in visualizzazione Web e per alcuni motivi non siamo riusciti a scoprire perché! Proviamo quasi tutte le soluzioni che sono state sul web, ma bloccate senza ricaricare usando location.reload () o soluzioni alternative come window.location.reload (), location.reload (true), ...!

Ecco la nostra soluzione semplice:

Basta usare un tag <a> con il valore di attribuzione "href" vuoto come questo:

< a href="" ...>Click Me</a>

(in alcuni casi è necessario utilizzare "return true" al clic del target per attivare la ricarica)

Per ulteriori informazioni, consulta questa domanda: un href vuoto è valido?

— Metro Polisue
fonte

-3

window.location.href, questo mi ha salvato la vita in webview da Android 5.1. La pagina non si ricarica con location.reload () in questa versione da Android.

— Rony Silva
fonte