这两条线有区别吗?
var url = "http://www.google.com/";
window.location = url;
window.location.replace(url);
这两条线有区别吗?
var url = "http://www.google.com/";
window.location = url;
window.location.replace(url);
window.location
将一个项目添加到您的历史记录中,您可以(或应该能够)单击“返回”并返回当前页面。
window.location.replace
替换当前历史记录项,因此您无法返回。
assign(url)
:在提供的 URL 处加载文档。
replace(url)
:将当前文档替换为提供的 URL 中的文档。与该方法的不同之处assign()
在于,使用replace()
当前页面后不会保存在会话历史中,这意味着用户将无法使用“后退”按钮导航到该页面。
哦,一般来说:
window.location.href = url;
优于:
window.location = url;
TLDR;
使用location.href
或更好地使用window.location.href
;
但是,如果您阅读本文,您将获得无可否认的证据。
事实是它很好用,但为什么要做有问题的事情。你应该走更高的路,按照可能应该做的方式去做。
location = "#/mypath/otherside"
var sections = location.split('/')
这段代码在语法、逻辑和类型方面都是完全正确的,你知道它唯一的错误吗?
它有location
而不是location.href
那这个呢
var mystring = location = "#/some/spa/route"
的价值是mystring
多少?有没有人真的不做一些测试就知道了。没有人知道这里到底会发生什么。见鬼,我只是写了这个,我什至不知道它是做什么的。location
是一个对象,但我正在分配一个字符串,它将传递字符串还是传递位置对象。可以说,应该如何实现它有一些答案。你能保证所有浏览器都会做同样的事情吗?
我几乎可以猜测所有浏览器都会处理相同的问题。
var mystring = location.href = "#/some/spa/route"
如果你把它放到打字稿中会不会因为类型编译器会说这是一个对象而中断呢?
然而,这种对话比单纯的location
对象要深刻得多。这种转换是关于你想成为什么样的程序员?
如果您走这条捷径,是的,今天可能还可以,明天可能还可以,该死的可能永远都可以,但是先生,您现在是一个糟糕的程序员。这对你不好,它会让你失望。
会有更多的对象。会有新的语法。
你可能会定义一个只接受一个字符串但返回一个对象的 getter,最糟糕的是你会认为你做的事情是正确的,你可能会认为你对这个聪明的方法很聪明,因为这里的人可耻地把你引入了歧途。
var Person.name = {first:"John":last:"Doe"}
console.log(Person.name) // "John Doe"
对于 getter 和 setter,这段代码实际上可以工作,但仅仅因为它可以完成并不意味着这样做是“明智的”。
大多数编程的人都喜欢编程并且喜欢变得更好。在过去的几年里,我变得非常好,学到了很多东西。我现在知道的最重要的事情,尤其是当您编写库时,就是一致性和可预测性。
做你能坚持做的事情。
+"2"
<-- 此处将字符串解析为数字。你应该使用它吗?还是应该使用parseInt("2")
?
怎么样var num =+"2"
?
从你所学到的,从stackoverflow的角度来看,我不太希望。
如果您开始遵循这两个词一致且可预测。您将知道 stackoverflow 上大量问题的正确答案。
让我告诉你这是如何得到回报的。通常我会放在;
我写的每一行 javascript 上。我知道它更具表现力。我知道这更清楚。我遵守了我的规则。有一天,我决定不去。为什么?因为很多人告诉我不再需要它,而 JavaScript 可以没有它。所以我决定这样做。现在,因为我已经确定了自己作为程序员的自我(因为你应该享受掌握一门语言的果实),所以我写了一些非常简单的东西,我没有检查它。我删除了一个逗号,我认为我不需要重新测试删除一个逗号这样简单的事情。
我在 es6 和 babel 中写了类似的东西
var a = "hello world"
(async function(){
//do work
})()
这段代码失败了,花了很长时间才弄清楚。由于某种原因,它看到的是
var a = "hello world"(async function(){})()
隐藏在源代码深处,它告诉我“hello world”不是一个函数。
为了更有趣,节点不显示转译代码的源图。
浪费了这么多愚蠢的时间。我也向某人展示了 ES6 是如何出色的,然后我不得不开始调试并展示 ES6 是多么的轻松和更好。没有说服力是。
我希望这回答了你的问题。这是一个古老的问题,更多的是为下一代,仍在学习的人。
当人们说这两种方法都行得通时提出问题。机会是一个更聪明更有经验的人会告诉你其他明智的。
如果有人覆盖了位置对象怎么办。他们将为旧浏览器做一个 shim。它将获得一些需要填充的新功能,并且您的 3 年旧代码将失败。
我要思考的最后一个笔记。
编写干净、清晰、有目的的代码会为您的代码做一些无法用正确或错误回答的事情。它的作用是使您的代码成为推动者。
您可以使用更多的插件、库,而不必担心代码之间的中断。
作为记录。采用
window.location.href
这两条线有区别吗?
window.location = "http://www.google.com/";
window.location.replace("http://www.google.com/");
是的。
首先,你想知道:
window.location = "https://stackoverflow.com"
是的别名,window.location.href = "https://stackoverflow.com"
因此具有相同的功能。
window.location
VSwindow.location.replace
window.location:
在这里,我window.location = "https://website.com"
在其上下文中作为window.location.href = "https://website.com"
window.location.replace:
要回答这个问题:
是的,我们的 2 个主题之间存在差异,主要在于window.location
允许您返回浏览器历史记录,而window.location.replace()
不允许您返回浏览器历史记录,从而从浏览器历史记录中删除之前的 URL 记录。
奖励:哪个更快?
当您使用 this 时:window.location = "http://www.google.com/";
您正在直接更新href
属性,这在性能上比使用更快,window.location.replace("http://www.google.com/");
因为更新函数比直接更新属性慢。
window.location
window.location
返回Location
内部看起来像这样的对象:
console.log(window.location);
// This is how the Location object that returns from window.location looks like
{
"ancestorOrigins": {},
"href": "https://stackoverflow.com/",
"origin": "https://stackoverflow.com",
"protocol": "https:",
"host": "stackoverflow.com",
"hostname": "stackoverflow.com",
"port": "",
"pathname": "/",
"search": "",
"hash": ""
}
该Location
对象还具有以下方法(功能):
Location.assign()
在参数中提供的 URL 加载资源。
Location.reload()
重新加载当前 URL,如刷新按钮。
Location.toString()
返回一个包含整个 URL 的字符串。它是 Location.href 的同义词,但不能用于修改值。