Qual é a diferença entre janela.localização= e janela.localizacao.substituir ()?

Há alguma diferença entre estas duas linhas?

var url = "http://www.google.com/";
window.location = url;
window.location.replace(url);
Author: Seth McClaine, 2009-12-08

2 answers

window.location adiciona um item ao seu histórico no qual você pode (ou deve ser capaz de) clicar em "voltar" e voltar para a página atual.

window.location.replace substitui o item Histórico actual para que não possa voltar a ele.

Ver window.location:

assign(url): carregar o documento em a URL fornecida.

replace(url):Substituir a corrente documento com o documento fornecido ENDERECO. A diferença em relação ao assign() o método é aquele que, após a utilização replace() a página actual irá nao ser gravado no histórico da sessão, significado o Usuário não será capaz de usar a parte de trás botão para navegar até ele.

De um modo geral:
window.location.href = url;

É favorecido em relação a:

window.location = url;
 424
Author: cletus, 2017-12-29 05:22:48

TLDR;

Utilizar location.href ou melhor Utilização window.location.href;

No entanto, se leres isto, terás provas inegáveis. A verdade é que não há problema em usar, mas porquê fazer coisas questionáveis. Você deve tomar a estrada mais alta e apenas fazê-lo da maneira que provavelmente deve ser feito.
location = "#/mypath/otherside"
var sections = location.split('/')

Este código é perfeitamente correcto em termos de sintaxe, lógica e tipo. sabes qual é o problema?

Tem location em vez de location.href

E que tal este

var mystring = location = "#/some/spa/route"
Qual é o valor de mystring? alguém realmente sabe sem fazer algum teste. Ninguém sabe exactamente o que vai acontecer aqui. Acabei de escrever isto e nem sei o que faz. location é um objecto, mas estou a atribuir uma cadeia de caracteres que irá passar a cadeia ou passar o objecto de localização. Digamos que há uma resposta para a forma como isto deve ser implementado. Pode garantir que todos os navegadores farão a mesma coisa? Acho que todos os navegadores tratarão do ... mesmo.
var mystring = location.href = "#/some/spa/route"

E se você colocar isto em typescript irá quebrar porque o compilador de tipo vai dizer que isso é suposto ser um objeto?

Esta conversa é muito mais profunda do que apenas o objecto. O que esta conversão é sobre que tipo de programador você quer ser? Se aceitares este atalho, sim, pode ficar tudo bem hoje, pode ficar tudo bem amanhã, pode ficar tudo bem para sempre, mas agora és um mau programador. Não vai ficar tudo bem. tu e ela vão falhar-te. Haverá mais objectos. Haverá uma nova sintaxe.

Você pode definir um getter que leva apenas uma cadeia de caracteres, mas retorna um objeto e a pior parte é que você vai pensar que você está fazendo algo correto, você pode pensar que você é brilhante para este método inteligente, porque as pessoas aqui têm vergonhosamente led do caminho certo.

var Person.name = {first:"John":last:"Doe"}
console.log(Person.name) // "John Doe"
Com getters e setters este código realmente funcionaria, mas só porque pode ser feito não significa que é 'sábio' fazer entao. A maioria das pessoas que programam adoram programar e adorar melhorar. Nos últimos anos, fiquei muito bom e aprendi muito. A coisa mais importante que eu sei agora, especialmente quando você escreve bibliotecas é consistência e previsibilidade. Faz as coisas que podes fazer consistentemente.

+"2" parseInt("2")?

E que tal var num =+"2"?

Do que tens aprenda, pelas mentes de stackoverflow eu não sou muito esperançoso.

Se começar a seguir estas 2 palavras de forma consistente e previsível. Você saberá a resposta certa para uma tonelada de perguntas sobre stackoverflow.

Deixa-me mostrar-te como isto compensa. Normalmente coloco ; em todas as linhas de javascript que escrevo. Sei que é mais expressivo. Sei que é mais claro. Segui as minhas regras. Um dia decidi não o fazer. Por quê? Porque há tanta gente a dizer-me que já não é preciso. e o JavaScript pode passar sem ele. Então, decidi fazer isto. Agora, porque eu me tornei seguro de mim mesmo como um programador (como você deve apreciar o fruto de dominar uma língua) eu escrevi algo muito simples e eu não verifiquei. Apaguei uma vírgula E pensei que não precisava de voltar a testar para algo tão simples como remover uma vírgula. Eu escrevi algo parecido com isso em es6 e babel.
var a = "hello world"
(async function(){
  //do work
})()
Este código falhou e demorou uma eternidade a descobrir. Por alguma razão o que viu era
var a = "hello world"(async function(){})()
Escondido no fundo do código fonte, dizia-me que" Olá mundo " não é uma função.

For more fun node doesn't show the source maps of transpiled code.

Perdi tanto tempo estúpido. Eu estava apresentando a alguém também sobre como ES6 é brilhante e então eu tive que começar a depurar e demonstrar como a dor de cabeça livre e melhor ES6 é. Não é convincente, pois não? Espero que isto tenha respondido à tua pergunta. Esta é uma pergunta antiga. geração futura, pessoas que ainda estão aprendendo. Pergunta quando as pessoas dizem que não importa de qualquer maneira funciona. É provável que uma pessoa mais sábia e experiente lhe diga o contrário. E se alguém sobrepuser o objecto da localização? Eles vão fazer um shim para navegadores mais velhos. Ele vai ter algum novo recurso que precisa ser shimmed e seu código de 3 anos de idade vai falhar. A minha última nota a ponderar. Escrever um código limpo e claro faz alguma coisa por ... o seu código que não pode ser respondido com certo ou errado. O que faz é tornar o teu código um facilitador.

Você pode usar mais plugins de coisas, bibliotecas com medo de interrupção entre os códigos.

Para que conste. utilização

window.location.href

 12
Author: Lpc_dark, 2016-01-14 02:41:29