So then in addition to being a way to know the current URL, it can also be used to preform a redirect to a new location by setting the value of the document location property to a string that is the new URL to go to. That is because although the object itself is read only a new URL can be set to the property that will cause the browser to load that new given URL that it has been set to. So there is using this location object to know the current location, and also using it to set a new location.
The href property of a location object can also be set to a url, and when doing so will result in a redirect to that url. Although the location object of the document location property is read only a DOMString can be set to the href property of this read only object, and when a new url is assigned to it that will result in a client side redirect to the url that is set to the href property of the location object.
For this example I am using the get elements by tag name method of the document object to get an html collection of all input elements in the page, I did it this way just for the sake of switching things up when it comes to how to go about getting an element reference. Anyway once I have an element object reference by one way or the other I then attached an event handler to the first input element by way of the add event listener method and the on click pointer event that will work with mouse and touch events.
The same can also be done with the location href property of the window object as well. In fact in most modern browsers there is not any note worth difference between the two, but that might not always be the case when it comes to older browsers. Some developers seem to suggest that the window location property should be used for this, and anything else that has to do with the location object of the page. However this is a post on document location so that is what I use that in this example, in production code though maybe window location would be best.
In some situations this can be useful if I am developing some kind of project that makes use of a resource that just does not play nice when someone chooses to open it up in the browser rather than hosting it with a web server. I can use the location protocol property as a way to fine out if the file protocol is being used, and if so display a message to tell the person using it that then need to host the file by way of http.
When it comes to serving a public html folder over the http protocol there are a lot of options to do so. I have wrote a post on a nodejs simple static sever script that would be one way to go about doing so with just nodejs itself. However when it comes to really getting into back end development with nodejs it might be best to look into frameworks as a way to save time such as with the express static method in express.
Much of the remaining values of a location object will depend on the protocol along with other factors. For example if I am looking at an html document via the file: protocol then the location object will not have a host name or port, because the url is just a path to a static resource located on my computer.
In a location object there is a host and hostname properties that can get the domain name if there is one to get depending on the protocol. For example if I create an html document and just open it up in the browser then the protocol is file: and then the values for host and hostname are empty strings. However if I host that file locally with an http server then the protocol will be http: and the host and hostname properties will not return an empty string.
The two properties more or less give the same thing, but with one note worth difference the hostname will also give a post if there is one in the url string.
So the values of many of these properties of course depending on the state of the url string. If the protocol is the file: protocol the of course I am not going to get a domain name, or port, because the url is just a path to a local asset.
The path name of the location object in document will refer to the path name after the protocol host name and port, and before any additional parts of the url afterwards such as query strings and hash tags to any items in the page
For this example I just wanted to test out of this reload method works as it should when called in the body of an event hander. So I set up a simple example that will just display a random number once when the page loads, so then the only way to go about getting a new random number would be to reload the page. With that said I also placed a button that when clicked will call the reload method of the location object.
I was thinking that this is an example of a kind of method that can end up being abused by developers to create a web page that will keep reloading over an over again. So I was thinking that there might be some kind of browser feature that would nit allow this. It would seem that I was wrong with that assumption at least in the version of chrome that I was using at the time of this writing as the below example that uses setTimeout works with the reload method.
So then because this reload method seems to work okay it can be used not just in event handers that are fired by some kind of user action, but also be used in a condition that can happen inside the body of some kind of application loop.
It would seem that in some browser environments document location and window location are the same thing, however in others they are not. It might be best to actually stick with window location because that might be more consistent across environments, but don’t just take my word for it there is a good thread on stack overflow on this one that is worth checking out.
So the document location property is very useful when it comes to client side redirects as well as knowing the current protocol and more about the current location of the page. Document location in most modern browsers seems to be the same thing as window location, but that should not always be assumed especially when it comes to older browsers, namely Internet explorer.