¿Cuál es la diferencia entre window.location = y window.location.replace ()?

¿Hay alguna diferencia entre estas dos líneas?

var url = "http://www.google.com/";
window.location = url;
window.location.replace(url);

window.location agrega un elemento a su historial en el que puede (o debería poder) hacer clic en "Atrás" y volver a la página actual.

window.location.replace reemplaza el elemento del historial actual para que no pueda volver a él.

Ver window.location:

assign(url): Cargue el documento en la URL proporcionada.

replace(url): Reemplace el documento actual con el de la URL proporcionada. La diferencia con el assign()método es que después de usar replace()la página actual no se guardará en el historial de la sesión, lo que significa que el usuario no podrá usar el botón Atrás para navegar hacia ella.

Ah y hablando en general:

window.location.href = url;

se favorece sobre:

window.location = url;

TLDR;

uso location.hrefo mejor uso window.location.href;

Sin embargo, si lee esto, obtendrá pruebas innegables.

La verdad es que está bien usarla, pero ¿por qué hacer cosas que son cuestionables? Debe tomar el camino más alto y hacerlo de la manera que probablemente debería hacerse.

location = "#/mypath/otherside"
var sections = location.split('/')

Este código es perfectamente correcto en cuanto a sintaxis, lógica, tipografía, ¿sabe lo único que tiene de malo?

tiene en locationlugar delocation.href

que hay de esto

var mystring = location = "#/some/spa/route"

¿Cuál es el valor de mystring? ¿Alguien sabe realmente sin hacer alguna prueba? Nadie sabe exactamente qué sucederá aquí. Diablos, acabo de escribir esto y ni siquiera sé lo que hace. locationes un objeto pero estoy asignando una cadena si pasará la cadena o pasará el objeto de ubicación. Digamos que hay alguna respuesta sobre cómo se debe implementar esto. ¿Pueden garantizar que todos los navegadores harán lo mismo?

Esto casi puedo adivinar que todos los navegadores manejarán lo mismo.

var mystring = location.href = "#/some/spa/route"

¿Qué pasa si coloca esto en mecanografiado se romperá porque el compilador de tipos dirá que se supone que es un objeto?

locationSin embargo, esta conversación es mucho más profunda que solo el objeto. ¿De qué se trata esta conversión de qué tipo de programador quieres ser?

Si tomas este atajo, sí, podría estar bien hoy, mañana podría estar bien mañana, demonios, podría estar bien para siempre, pero ahora eres un mal programador. No estará bien para ti y te fallará.

Habrá más objetos. Habrá una nueva sintaxis.

Puede definir un captador que tome solo una cadena pero devuelva un objeto y la peor parte es que pensará que está haciendo algo correcto, podría pensar que es brillante para este método inteligente porque la gente aquí lo ha llevado vergonzosamente por mal camino.

var Person.name = {first:"John":last:"Doe"}
console.log(Person.name) // "John Doe"

Con getters y setters, este código realmente funcionaría, pero solo porque se puede hacer no significa que sea 'SABIO' hacerlo.

A la mayoría de las personas que programan les encanta programar y les encanta mejorar. En los últimos años me he vuelto bastante bueno y he aprendido mucho. Lo más importante que sé ahora especialmente cuando escribes Bibliotecas es la consistencia y la previsibilidad.

Haz las cosas que puedas hacer constantemente.

+"2"<- esto aquí analiza la cadena a un número. deberías usarlo? o deberías usar parseInt("2")?

¿qué pasa var num =+"2"?

De lo que has aprendido, de las mentes de stackoverflow no estoy muy esperanzado.

Si comienza a seguir estas 2 palabras consistentes y predecibles. Conocerá la respuesta correcta a un montón de preguntas sobre stackoverflow.

Déjame mostrarte cómo vale la pena. Normalmente pongo ;en cada línea de javascript que escribo. Sé que es más expresivo. Sé que está más claro. He seguido mis reglas. Un día decidí no hacerlo. ¿Por qué? Porque mucha gente me dice que ya no es necesario y que JavaScript puede prescindir de él. Entonces, lo que decidí hacer esto. Ahora, porque me he asegurado de mí mismo como programador (ya que debería disfrutar el fruto de dominar un idioma), escribí algo muy simple y no lo comprobé. Borré una coma y no pensé que fuera necesario volver a hacer una prueba para algo tan simple como quitar una coma.

Escribí algo similar a esto en es6 y babel

var a = "hello world"
(async function(){
  //do work
})()

Este código falla y tardó una eternidad en darse cuenta. Por alguna razón, lo que vio fue

var a = "hello world"(async function(){})()

oculto en lo profundo del código fuente que me decía "hola mundo" no es una función.

Para mayor diversión, el nodo no muestra los mapas fuente del código transpilado.

Perdí tanto tiempo estúpido. También le estaba presentando a alguien sobre cómo ES6 es brillante y luego tuve que comenzar a depurar y demostrar cuán libre de dolor de cabeza y mejor es ES6. No es convincente.

Espero que esto haya respondido tu pregunta. Esta es una vieja pregunta, es más para la generación futura, las personas que todavía están aprendiendo.

Pregunta cuando la gente dice que no importa de ninguna manera funciona. Es probable que una persona más sabia y con más experiencia le diga lo contrario.

¿Qué pasa si alguien sobrescribe el objeto de ubicación? Harán una cuña para los navegadores más antiguos. Obtendrá alguna nueva característica que debe ser modificada y su código de 3 años fallará.

Mi última nota para reflexionar.

Escribir un código claro y claro hace algo para su código que no puede responderse con lo correcto o incorrecto. Lo que hace es que su código sea un habilitador.

Puede usar más complementos, bibliotecas sin temor a la interrupción entre los códigos.

para el registro. utilizar

window.location.href