Jaka jest różnica między window.location = a window.location.replace ()?

Czy istnieje różnica między tymi dwiema liniami?

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

window.location dodaje element do swojej historii, w którym możesz (lub powinnaś móc) kliknąć „Wstecz” i wrócić do bieżącej strony.

window.location.replace zastępuje bieżący element historii, więc nie można do niego wrócić.

Zobacz window.location:

assign(url): Załaduj dokument pod podanym adresem URL.

replace(url): Zastąp bieżący dokument dokumentem pod podanym adresem URL. Różnica w stosunku do assign()metody polega na tym, że po użyciu replace()bieżącej strony nie zostanie zapisana w historii sesji, co oznacza, że ​​użytkownik nie będzie mógł użyć przycisku Wstecz, aby do niej przejść.

Aha i ogólnie mówiąc:

window.location.href = url;

jest uprzywilejowany:

window.location = url;

TLDR;

używać location.hreflub lepiej wykorzystywać window.location.href;

Jednak jeśli to przeczytasz, uzyskasz niezaprzeczalny dowód.

Prawda jest w porządku, ale po co robić rzeczy, które są wątpliwe. Powinieneś wybrać wyższą drogę i po prostu zrobić to tak, jak to prawdopodobnie powinno być zrobione.

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

Ten kod jest całkowicie poprawny pod względem składniowym, logicznym, typowym, czy wiesz, że jest z nim tylko jedna rzecz?

ma locationzamiastlocation.href

a co z tym

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

Jaka jest wartość mystring? czy ktoś naprawdę wie bez przeprowadzania jakiegoś testu. Nikt nie wie, co dokładnie się tutaj stanie. Do diabła, właśnie to napisałem i nawet nie wiem, co to robi. locationjest obiektem, ale przypisuję ciąg, czy przejdzie on przez ciąg, czy przekaże obiekt lokalizacji. Powiedzmy, że istnieje odpowiedź na pytanie, w jaki sposób należy to zaimplementować. Czy możesz zagwarantować, że wszystkie przeglądarki zrobią to samo?

Mogę zgadnąć, że wszystkie przeglądarki będą działać tak samo.

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

A jeśli umieścisz to w maszynopisie, czy to się zepsuje, ponieważ kompilator typów powie, że to ma być obiekt?

Ta rozmowa jest jednak o wiele głębsza niż sam locationprzedmiot. Co to za konwersja dotyczy tego, jakim programistą chcesz być?

Jeśli skorzystasz z tego skrótu, to może być dziś w porządku, jutro może być w porządku, do diabła, może być w porządku na zawsze, ale pan jest teraz złym programistą. To nie będzie dla ciebie w porządku i zawiedzie cię.

Będzie więcej obiektów. Pojawi się nowa składnia.

Możesz zdefiniować moduł pobierający, który pobiera tylko ciąg znaków, ale zwraca obiekt, a najgorsze jest to, że pomyślisz, że robisz coś poprawnie, możesz pomyśleć, że jesteś genialny w tej sprytnej metodzie, ponieważ ludzie tutaj wstydliwie wprowadzili cię w błąd.

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

W przypadku programów pobierających i ustawiających ten kod faktycznie działałby, ale sam fakt, że można to zrobić, nie oznacza, że ​​jest to „WISE”.

Większość ludzi, którzy programują, uwielbia programować i uwielbia się poprawiać. W ciągu ostatnich kilku lat stałem się całkiem dobry i wiele się nauczyłem. Najważniejszą rzeczą, którą wiem teraz, szczególnie podczas pisania Bibliotek, jest spójność i przewidywalność.

Rób rzeczy, które możesz konsekwentnie robić.

+"2"<- to tutaj parsuje ciąg do liczby. powinieneś go użyć? czy powinieneś użyć parseInt("2")?

co var num =+"2"?

Z tego, czego się nauczyłeś, z umysłów stackoverflow nie mam nadziei.

Jeśli zaczniesz przestrzegać tych 2 słów spójnych i przewidywalnych. Poznasz prawidłową odpowiedź na mnóstwo pytań dotyczących przepływu stosu.

Pokażę ci, jak to się opłaca. Zwykle umieszczam ;na każdej linii javascript, którą piszę. Wiem, że to bardziej ekspresyjne. Wiem, że to bardziej jasne. Przestrzegałem moich zasad. Pewnego dnia postanowiłem tego nie robić. Czemu? Ponieważ tak wiele osób mówi mi, że nie jest to już potrzebne, a JavaScript może się bez niego obejść. Więc co postanowiłem to zrobić. Teraz, ponieważ nabrałem pewności siebie jako programisty (ponieważ powinieneś cieszyć się owocem opanowania języka), napisałem coś bardzo prostego i nie sprawdziłem tego. Usunąłem jeden przecinek i nie sądziłem, że muszę ponownie testować tak prostą rzecz jak usunięcie jednego przecinka.

Napisałem coś podobnego do tego w es6 i babel

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

Ten kod zawiódł i zajęło to wieczność. Z jakiegoś powodu to, co zobaczył

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

ukryty głęboko w kodzie źródłowym mówił mi, że „witaj świecie” nie jest funkcją.

Dla większej zabawy węzeł nie pokazuje map źródłowych transpilowanego kodu.

Zmarnowałem tyle głupiego czasu. Przedstawiłem komuś także, jak ES6 jest genialny, a potem musiałem zacząć debugować i zademonstrować, jak wolny jest ból głowy i jak lepiej ES6. Nie jest to przekonujące.

Mam nadzieję, że to odpowiedziało na twoje pytanie. To stare pytanie, które dotyczy bardziej przyszłych pokoleń, ludzi, którzy wciąż się uczą.

Pytanie, kiedy ludzie mówią, że to nie ma znaczenia, czy tak to działa. Szanse są mądrzejsze, bardziej doświadczona osoba powie innym mądrym.

co jeśli ktoś zastąpi obiekt lokalizacji. Zrobią wstrząs dla starszych przeglądarek. Otrzyma nową funkcję, którą należy zmienić, a twój 3-letni kod zawiedzie.

Moja ostatnia uwaga do przemyślenia.

Pisanie czystego, przejrzystego i celowego kodu robi coś dla twojego kodu, na który nie można odpowiedzieć poprawnie lub źle. To sprawia, że ​​twój kod aktywuje.

Możesz korzystać z większej liczby wtyczek, bibliotek bez obawy o przerwanie między kodami.

dla przypomnienia. posługiwać się

window.location.href