Respuestas:
Si no recuerdo window.location.reload()mal , vuelve a cargar la página actual con datos POST, mientras window.location.href=window.location.hrefque no incluye los datos POST.
Como señaló @ W3Max en los comentarios a continuación, window.location.href=window.location.hrefno volverá a cargar la página si hay un ancla (#) en la URL: debe usarwindow.location.reload() en este caso.
Además, como lo señala @Mic a continuación, window.location.reload()toma un argumento adicional skipCachepara que con el uso window.location.reload(true)del navegador se salteará el caché y volverá a cargar la página desde el servidor. window.location.reload(false)hará lo contrario y cargará la página desde el caché si es posible.
Si dice que window.location.reload(true)el navegador omitirá el caché y volverá a cargar la página desde el servidor.window.location.reload(false)Hará lo contrario.
Nota: el defaultvalor para window.location.reload()esfalse
window.location.href = window.location.hreffuncionó.
location.reload()o location.reload(false). Para hacer una actualización completa de la página, use location.reload(true).
La diferencia es que
window.location = document.URL;
no volverá a cargar la página si hay un hash (#) en la URL (con o sin algo después), mientras que
window.location.reload();
volverá a cargar la página.
location.href = location.hrefpor sentado, pero me di cuenta de ese comportamiento exacto y vine a SO para correr la voz. Solo use location.reload()en su lugar.
window.location.replace(window.location.pathname);
Si agrega boolean true a la recarga
window.location.reload(true), se cargará desde el servidor.
No está claro cómo apoyó esta booleana es, W3Org menciona que NS utiliza para apoyar su
Puede haber una diferencia entre el contenido de window.location.href y document.URL - hay al menos solía ser una diferencia entre location.href y la no-estándar y obsoleta document.location que tenía que ver con el cambio de dirección, pero eso Es realmente el último milenio.
Para fines de documentación, usaría window.location.reload () porque eso es lo que quieres hacer.
Como se dijo, modificar la href cuando hay un hash (#) en la url no volvería a cargar la página. Por lo tanto, uso esto para recargarlo en lugar de expresiones regulares:
if (!window.location.hash) {
window.location.href = window.location.href;
} else {
window.location.reload();
}
Encontré esta pregunta investigando un comportamiento aberrante en IE, específicamente IE9, no verificó versiones anteriores. Parece
window.location.reload();
da como resultado una actualización que borra toda la pantalla por un segundo, donde
window.location = document.URL;
actualiza la página mucho más rápido, casi imperceptiblemente.
Investigando un poco más, y experimentando un poco con el violinista, parece que window.location.reload()omitirá el caché y se volverá a cargar desde el servidor, independientemente de si pasa el booleano con él o no, esto incluye obtener todos sus activos (imágenes, scripts, hojas de estilo, etc) de nuevo. Entonces, si solo desea que la página actualice el HTML, window.location = document.URLvolverá mucho más rápido y con menos tráfico.
Una diferencia en el comportamiento entre los navegadores es que cuando IE9 usa el método de recarga, borra la página visible y aparentemente la reconstruye desde cero, donde FF y Chrome esperan hasta que obtengan los nuevos activos y los reconstruyan si son diferentes.
Una diferencia en Firefox (12.0) es que en una página renderizada desde una POST, reload () mostrará una advertencia y volverá a publicar, mientras que una asignación de URL hará un GET.
Google Chrome hace un GET para ambos.
Usando JSF, ahora tengo el problema con la actualización después de que la sesión ha expirado: PrimeFaces ViewExpiredException después de volver a cargar la página y con un poco de investigación he encontrado una diferencia en FireFox:
Las llamadas window.location.reload()funcionan como hacer clic en el icono de actualización en FF, agrega la línea
Cache-Control max-age=0
Si bien la configuración window.location.hreffunciona como presionar ENTRAR en la línea URL, no envía esa línea.
Aunque ambos se envían como GET, el primero (recargar) está restaurando los datos anteriores y la aplicación está en estado inconsistente.
Desde mi experiencia de unos 3 años, no pude encontrar ninguna diferencia ...
editar: sí, como uno de ellos ha dicho aquí, solo pasar un parámetro booleano a window.location.reload () es la diferencia. si pasa verdadero , el navegador carga una página nueva, pero si es falso , se carga la versión de caché ...
En nuestro caso, solo queremos volver a cargar la página en la vista web y, por alguna razón, ¡no pudimos descubrir por qué! Probamos casi todas las soluciones que han estado en la web, pero que no se han recargado utilizando location.reload () o soluciones alternativas como window.location.reload (), location.reload (true), ...!
Aquí está nuestra solución simple:
Simplemente use una etiqueta <a> con el valor de atribución "href" vacío como este:
< a href="" ...>Click Me</a>
(en algunos casos, debe usar "return true" al hacer clic en el objetivo para activar la recarga)
Para obtener más información, consulte esta pregunta: ¿es válida una href vacía?
window.location.href, esto me salvó la vida en la vista web desde Android 5.1. La página no se recarga con location.reload () en esta versión de Android.