I'm using JQuery, latest version.
$(document).ready(function(){
function ViewModel(){
this.Impossible = "impossible!";
}
let vm = ViewModel();
});
$(window).on("beforeunload", function (e) {
console.log("this: " + this.Impossible);
console.log("window: " + window.Impossible);
// return "Test";
});
https://jsfiddle.net/5wkdxvhq/1/
How is it possible that "impossible!" gets logged? Impossible is wrapped by at least 2 functions, it definitely shouldn't be a global variable, yet there it is.
Is this a behavior of JQuery or JavaScript?
Is this standard behavior that I can rely on? Or is it some quirk that won't work in other browsers/future Knockout updates or a bad design practice by me?
Impossible isn't wrapped up by your functions declarative/lexical environments. It isn't local to your innermost function. If it was declared like this:
let Impossible = "impossible!"
//or
//var Impossible = "impossible!"
Then Impossible would have been local to that function and there wouldn't be any way to access it unless you use a closure.
What this does:
this.Impossible = "impossible!"
Is create a property definition on the this object. The value of this of course will change depending on the invocation of the surrounding function (ViewModel). In this case, you have called ViewModel() which means there's no object context and on scripts (non-strict mode) it will default to the global object (window).
Had you call it like this: new ViewModel() it would have created a new object and that would have been your this object which would have been assigned to your vm variable (and only accessible through it).
Firstly, $(document).ready(function (){}) apply global scope to the callback function function (){}. Try this, you will see console.log(this) is a Window object.
$(document).ready(function(){
console.log(this);// this is window (global) object
});
Secondly, this is different when calling function and creating an object instance of a function, i.e let vm = ViewModel(); vs let vm = new ViewModel();.
function f1 () {
function f2 () {
console.log(this === window);
}
f2()
}
f1()
In your case, by creating instance of ViewModel, you will see the different values of window.Impossible
$(document).ready(function(){
function ViewModel(){
this.Impossible = "impossible!";
}
let vm = new ViewModel(); /// create instance instead of calling
console.log('vm:' + vm.Impossible);
console.log("this: " + this.Impossible);
console.log("window: " + window.Impossible);
});
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
Related
I am new to JavaScript and have a question to ask. When creating a new programme is it best to create all of my functions within a global variable/object or to create them all separate.
For example this:
var register = {
members: [],
Member: function(){
},
reset: function(){
},
printMembers: function(){
},
process: function(){
}
};
function init(){
register.process();
};
window.onload = init();
Or instead like this:
var members = [];
function Member(){
};
function reset(){
};
function printMembers(){
};
function process(){
};
function init(){
process();
};
window.onload = init();
This may be a very stupid question to ask...
When creating a new programme is it best to create all of my functions within a global variable/object or to create them all separate.
This is kind of opinion based, but I'll give you a good reason for creating all your properties inside a global object: you won't pollute the namespace. That means, you won't be creating a lot of global objects, that would be properties of the global object (window, in browsers).
If you use someone else's library, and if both you and him would create global objects, the script that was included later in the HTML would override properties with the same name declared in the other script.
Finishing, I would suggest you to write your code like:
var app = {};
app.members = [];
app.Member = function(){};
app.reset = function(){};
app.printMembers = function(){};
app.process = function(){};
function init() {
app.process();
};
window.onload = init;
Also, note that you should do window.onload = init, and not window.onload = init().
The difference:
with window.onload = init, you are setting the onload property in window to be the init function. Later, when the page finishes loading, someone will ask the window to execute its onload property, and window will then do something like this.onload().
with window.onload = init(), you are executing init right there and setting the onload property of window to be the return of the execution of the init function. Since every Javascript function returns something (by default, undefined), you'll be setting window.onload = undefined. And this is not what you want.
It's a matter of taste style--kindof like writing an essay. Ultimately, what's important is that anyone (or you, six months from now) can read through your code and understand what's going on. Just focus on functionality and you will naturally start making decisions about what's logical where.
(Eloquent Javascript)[http://eloquentjavascript.net//] is also a great book on the subject.
I have a simple thing like this:
function init() {
var $something = 'something';
}
jQuery(document).ready(function($) {
init();
alert($something);
}
I thought this would work, but it doesn't, console says that $something is not defined. What's the issue?
Many thanks!
$something is defined within the scope of the function 'init' so you will only ever be able to access it from within that function as it is. If you wanted to get a value back, you could return it, like so:
function init() {
var $something = 'something';
return $something;
}
jQuery(document).ready(function($) {
var $something = init();
alert($something);
}
Notice that both those variables have the same name (normally a bad idea). They are each defined within their own scope, and thus they are totally different variables.
An alternate pattern might be to wrap the entire thing and use that scope, like so:
(function () {
var $something;
function init() {
$something = 'something';
}
jQuery(document).ready(function($) {
init();
alert($something);
}
})();
That way you have a single variable, but you avoid polluting the global namespace.
Edit:
In response to your comment, the above could be written like:
var newscope = function () {
var $something;
function init() {
$something = 'something';
}
jQuery(document).ready(function($) {
init();
alert($something);
}
}
newscope();
But I have defined the function AND called it at basically the same time without having to give it a name.
This is a scoping issue.
$something is defined within the scope of the init() function, and therefore, it will be disposed of when the init() function completes.
Vars declared with var will be local to the closure in which they are declared. As you've found, this means, therefore, that outside of that closure they are not reachable.
There's many ways round this and each means a different design pattern. Here's one pattern you could use:
({
init: function() {
this.something = 'hello';
jQuery(function() { this.dom_ready(); }.bind(this));
},
dom_ready: function() {
//DOM code here
alert(this.something); //hello
}
}).init();
Here I declare several methods of an object, or namespace. Since they belong to, and are called in the context of, this one object, they communicate between one another with properties rather than variables.
Variables are thus demoted to being useful only within (but never outside of) the closure in which they are declared.
One advantage of this pattern is that you can separate any code that needs to wait for the DOM to be ready from any code that doesn't. This is achieved by having a dedicated dom_ready method.
I have defined the following module globally:
var module = (function () {
console.log(this);
this.fn = function () {
console.log(this);
}
return this;
})();
http://www.quirksmode.org/js/this.html :
In JavaScript |this| always refers to the “owner” of the function we're executing, or rather, to the object that a function is a method of.
The first call to console.log logs Window as the value of this, and that I understand. But, so does also the second call to console.log.
Since this refers to the owner of the function, why does module.fn log Window and not module?
When I call fn I still have to write module.fn, I can't write Window.fn. Since this refers to Window I find this confusing.
EDIT: I forgot to return this in my example.
Since this refers to the owner of the function, why does module.fn log Window and not module?
The return value of the outer function is window because it doesn't get called in any particular context, so module ends up being window as well.
It seems that the way you have applied the module pattern is wrong. It should be returning the public interface that gets used in the rest of your code:
var module = (function () {
console.log(this);
// public interface
return {
fn: function () {
console.log(this);
}
}
})();
module.fn(); // "Object {fn: function}"
In your example, the global object receives the fn. It is the window object in case of browsers. That is because you are calling the function in place (effectively constructing a new scope) without specific context.
On the end, your module object is just a reference to the window (because of return this;).
What is this?
In JavaScript, this is the current context, the object on which the function was called that particular time. It is not the "holder" of the function. You can always "steal" the method from other objects and apply (literally) it to your own.
Assume you want to slice the arguments object for some reason. It looks just like an array, but it is NOT an array. arguments.slice(2,4) does not work (assuming ECMAScript < 5). What to do?
Array.prototype.slice.apply(arguments, [2,4]);
You need to steal the slice function from the Array prototype, and use if on your arguments. Inside the slice call, the "this" is the arguments object that particular time.
How to construct a valid module?
Your job is to return the module object. You do not want do mess with the context. It is not relevant, as long as you are not applying the function directly on module object.
The easiest solution is the simplest.
var module = (function() {
// do something internally, great for "private" stuff
// then return the "public" interface
return {
doSomething: function() {
// do something
},
introduce: function() {
console.log(this);
}
};
})();
module.introduce(); // Object {doSomething: function, introduce: function}
module.doSomething();
The other way.
Alternatively, you could use the this to do your job, using the apply, if you really want to.
var module = {};
(function(){
this.doSomething = function() {
// do something
};
this.introduce = function() {
console.log(this);
};
}).apply(module);
module.introduce(); // Object {doSomething: function, introduce: function}
module.doSomething();
Note this is almost equal to the "new" call.
There are more equally valid ways to do it, but the first presented one is frequently used and very clear. Anyway, everything really depends on your code conventions.
Your pattern is wrong what you are doing to make a closed scope and setting module to the return from that scope:
// This is the design pattern:
var module = (function () {
var module = {};
var localVar = 1;
module.moduleVar = 2;
module.fn = function () {
console.log(this);
}
return module;
})();
console.log(module.fn); // function() { console.log(this) ;}
console.log(module.moduleVar); // 2
console.log(module.localVar); // undefined
In the following customized class in javascript, in callback, why does this.obj have nothing but local variable obj has thing I want? Thanks.
function ClassTest(director) {
this.obj = {"test1": "test1"};
}
function test1(input, callback) {
callback("success");
}
ClassTest.prototype.test = function() {
var obj = this.obj;
test1("niuniu",function(e){
console.log(this.obj); // undefined
console.log(obj); // this one has stuff
});
}
// run
new ClassTest().test()
Because the function inside test1 is creating a new scope with different this context. Typical solutions are to bind or to cache this:
Binding:
test1("niuniu",function(e){
console.log(this.obj);
}.bind(this));
Caching:
var self = this;
test1("niuniu",function(e){
console.log(self.obj);
});
As for this line of code:
console.log(obj); // this one has stuff
The reason it works has to do with how JavaScript closure works. The code defined in your anonymous function has access to all variables in its local scope as well as variables defined in encompassing scopes and therefore obj is available. See How do JavaScript closures work? for more on closure.
The keyword this however, is a reference to the current scope. Because you are accessing this.obj from within the anonymous function, this refers to the anonymous function itself - which has no obj property defined. In the enclosing function, which is extending the ClassTest prototype, this refers to the current ClassTest object, which does have a obj property defined.
I saw in many source codes:
var me = this;
specially in Ext-JS 4 (JS framework). Why doing such thing? Is there any other reason or you just want for a variable to be called like "me" instead of "this"?
Thank you.
Usually so you can keep a reference to this inside a scope in which this refers to something else (like a callback function, for example).
Consider this example, in which the click event handler function has a different context to what you may expect (this doesn't refer to an instance of MyClass):
var MyClass = function (elem) {
this.elem = elem;
this.name = "James";
elem.addEventListener("click", function () {
alert(this.name); //oops
}, false);
};
Now consider this example, in which we store a reference to the value of this inside the constructor function, and use that inside the callback function:
var MyClass = function (elem) {
var me = this;
this.elem = elem;
this.name = "James";
elem.addEventListener("click", function () {
alert(me.name); //works!
}, false);
};
The callback function can refer to a variable that was declared in the outer function, even after that function has returned (the MyClass constructor returns as soon as it's executed the addEventListener). This is a demonstration of a closure.
Though of course closures are the more obvious reason for doing this, I just wanted to add that another reason can be to reduce the size of the minified version of a javascript file.
this as a keyword cannot be renamed in the process of minifying the file, while a local variable can. In other words, whenever you would use this (4 characters), instead a 1 character local variable can be used.
Consider the following example function of ExtJS's Ext.data.Store:
filterBy: function(fn, scope) {
var me = this;
me.snapshot = me.snapshot || me.data.clone();
me.data = me.queryBy(fn, scope || me);
me.fireEvent('datachanged', me);
me.fireEvent('refresh', me);
}
(note there's no closure involved here)
and its minified version:
filterBy:function(b,a){var c=this;c.snapshot=c.snapshot||c.data.clone();c.data=c.queryBy(b,a||c);c.fireEvent("datachanged",c);c.fireEvent("refresh",c)}
(151 characters/bytes)
Now, let's compare it to the minified version if we did not assign this to a local variable:
filterBy:function(b,a){this.snapshot=this.snapshot||this.data.clone();this.data=this.queryBy(b,a||this);this.fireEvent("datachanged",this);this.fireEvent("refresh",this)}
(170 characters/bytes)
As you can see the version with a local variable only takes 88% of the size of the function which uses this each time instead.
Especially in big libraries this can reduce the file size quite a bit.
Setting me=this allows you to use the this variable from an outer scope in an inner scope.
var Outer= function () {
var me = this;
me.x = "outerx";
me.inner = {
x: "innerx",
displayValues: function () {
console.log(me.x); //outerx
console.log(this.x); //innerx
}
};
};
new Outer().inner.displayValues();
Basically this utilizes closure in javascript. Read this about closure.
It is used to carry the particular instance of this to function calls where this has a different meaning.