In sample code of the yui library, I see this notation:
var obj = document.getElementById("coffee_msg");
obj.style.display = 'block';
As obj is only used once, I would rather prefer this:
document.getElementById("coffee_msg").style.display = 'block';
Is there any reason why the first notation is used in the yui library and many other places?
Are there incompatibilities with certain browsers?
If you only need to set one property it doesn't matter at all (as long as you do not want to check if the return value is valid before trying to access a property of it).
However, if you have multiple properties you'll want to do the lookup only once (even though an id lookup is extremely fast), so assigning the element to a variable is the way to go in that case.
Of course you could make this even shorter with jQuery: $('#coffee_msg').show()
Also has the advantage that you do not get an error if the element does not exist for some reason. And if you want to set multiple CSS properties etc, you can simply use a function that does that for you with a single call or chain multiple calls to different jQuery methods.
The two different ways work exactly the same. Using a temporary obj variable could be useful to improve readability of the code (but it should be given a name better than obj in that case).
There isn't a "real" reason, just to make the code a little bit more readable.
Just like with:
var myAge = 26;
var myAgeNextYear = myAge + 1;
VS:
var myAgeNextYear = 26 + 1;
My personal preference is to keep a reference to the obj only if I'm using it more than once.
The first option is useful because it improves readability, it also makes the obj variable available immediately for other use. I would use this example personally.
Related
I have a function that is called every 1 second.
var latestObject; //this updated separately, it depends on user input so it may not be different every second
var previousObject;
function Tick(object) {
if (latestObject !== previousObject) { //Problem is here
previousObject = latestObject; //or here
//do stuff with latestObject;
}
}
However when latestObject is updated it's properties are changed, the variable is not set to a different object. So previousObject and latestObject are always equal and the do stuff never happens.
I could do:
function Tick(object) {
var latestObjectString = JSON.stringify(latestObject);
if (latestObjectString !== previousObject) { //Problem is here
previousObject = latestObjectString; //or here
//do stuff with latestObject;
}
}
But then I'm doing JSON.stringify once every second, this seems inefficient, especially as latestObject is quite big, and quite deep.
Wouldn't it be better set previousObject to be a copy of latestObject, so that when properties on latestObject are changed, previousObject stays the same, and then this only happens when the objects are different which is less often than every second? But wouldn't there be a problem as copyOfObject == Object would never be true?
(the object is mostly properties, but has a few functions that don't ever change).
(No jQuery)
Description of the problem
The problem here is indeed related to the fact, that the same object is assigned to two different variables. Even if you change it in one place, the other changes it also.
This example shows you what really happens (jsFiddle: http://jsfiddle.net/tadeck/4hFC2/):
var objA = {'a':10, 'b': 20};
var objB = objA; // same instance assigned to both names
objB.a = 30; // instance is modified, its "a" property is changed
// now, both objA.a and objB.a show "30", as objA and objB is the same instance
However, having two different objects is not so ideal either, as comparing them is non-trivial (proof here: http://jsfiddle.net/tadeck/GN2m4/).
Solution no. 1. for comparing the objects
To solve this problem:
You need to use two different objects (eg. by using some solution similar to jQuery's .extend() to construct new object from existing object). You currently achieve that part using unnecessary serialization.
You need to compare them in a little more complex way (pretty universal solution for that is here: https://stackoverflow.com/a/1144249/548696).
In comparison to this, your solution may look less complex (at least in terms of code). I suggest using some JS performance tests to find out, which is more reasonable. JSON.stringify() is not always natively supported, so it may be doing things similarly complex (and resource-consuming), as the alternative solution I mentioned.
Solution no. 2. for solving the overall issue of detecting the changes
The other option is to rebuild your script and use eg. flags for marking the object as changed by user input. That would save you the processing of whole objects each second and may result in large efficiency gains.
The things you need to do in this case, are:
In your user-input handlers set the flag whenever user changes some part of the object,
Optionally, you could first compare the specific value with the original object (if user has changed it quickly and then reverted the change, just mark the value as not changed),
To limit the processing of the changed object, you could even mark, which properties were changed (so you process only these properties, nothing else),
To achieve part of this solution, you could even use JavaScript setters and getters, as described by John Resig.
But, as I mentioned, it may require rebuilding your script (which we haven't seen, so we cannot say if it is necessary or it can be applied rather easily).
My code -
<script type="application/javascript">
var firstObject = {
sayHello : function(){
document.write("My name is "+ this.myName +"<br>");
},
myName : "Swapnesh Sinha"
};
var secondObject = {myName : "Sanjay Sinha"};
document.write("First one " + firstObject.sayHello() );
document.write("<br>");
document.write("Second one "+ secondObject.myName);
</script>
Source - http://learn.jquery.com/javascript-101/this-keyword/
Expecting output -
First one Swapnesh Sinha
Second one Sanjay Sinha
Unexpected Output (from my sense)-
My name is Swapnesh Sinha
First one undefined
Second one Sanjay Sinha
Let me know the case why it returns undefined however source is mentioning to return name ? or something I am getting wrong from my side
In your first document.write, you call a function, and ask the return value of the function to be concatenated to the string "First one ".
The function is evaluated, at which point "My name is Swapnesh Sinha" gets outputed via document.write call inside the object. That function call however does not return a value, hence it is undefined, and that gets concatenated to "First one", which is then printed.
Here is the working fiddle: JsFIDDLE
Here is what you fail to understand, as most jQuery developers: JavaScript scoping.
Basically, in order for a property to be accessed via this, it has to be nested in the Object.prototype.
Correction
When you define the object properties inline, calling this will still point to the right object. However, the pattern I gave you, even though less popular, is a much neater and better approach.
The prototype is the JavaScript way of OOP. If you are looking for solid OOP style JS and for proper definition of models, improved code maintainability and better coding style, it is preferred to define classes using the pattern I gave you, as it will allow you to make a strong distinction between static functions and classes. It is also the natural flow of JavaScript, where everything is an object.
In high level JavaScript programming(powerful Ajax applications or applications where for one reason or the other the browser has to perform more advanced computation), the below style is always preferred. Static functions placed under a namespace are still defined separately:
var namespace = {};
namespace.firstStaticFunc = function() {/*do stuff etc;*/};
namespace.secondStaticFunc = function() { return !1; };
The only reason why you use your definition pattern is enums and hash maps. For instance:
var typesOfChicken = {
RED: 'red',
BLUE: 'blue'
};
The above is always used for things like internationalization and avoidance of hard coded values. Also, it helps JS minifiers to a better job. Given the above, you can say:
console.log(typesOfChicken.RED);// will print red.
console.log("red");// wil still print red
But, when I want to change red to something else, using enums I only have to do a single change. Also, the minifier can replace typesOfChicken.RED with a.b, whereas "RED" will always be "RED". It's unminifiable.
var firstObject = function() { };
firstObject.prototype.myName = "Swapnesh Sinha";//this will not be nested as an instance property.
firstObject.prototype.sayHello = function() {
alert(this.myName);// will now correctly display Swapnesh Sinha
};
// to use your first object.
var instance = new firstObject();
instance.sayHello();
To properly make use of scope, use the pattern I gave you, which is an Object Oriented pattern and the right approach to defining classes in JS.
And now you have a great way to organize your JavaScript code, it's fair easier to maintain, scope is a lot more obvious and most important of all you can immediately make a distinction between static functions and classes.
replace document.write() with return in your sayHello function
I need to make a Javascript object that would behave as an associative array, but with some functions that are called before getting and setting properties.
For example, the task may be like this: we should make an object, that would contain a squared value of a key, like this:
obj.two should be equal to 4,
obj.four should be equal to 16,
obj['twenty one'] should be equal to 441.
This is an example. Actually I need to make setting operation overridden too. The getting and setting operations would go to the database, and they not necceserily would take strings as keys, but any types of objects, from which it would create a DB query.
How would I do that a) with as less thirdparty libraries as possible and b) to make it work on as much platforms as possible?
I am new to JS, I've found that JS has no associative arrays, relying on the ability to define objects on the fly with arbitrary properties. I googled and had an idea to use or even override lookupgetter (and setter), where define a new getter/setter on the fly, but I coundn't find if the interpreter would use this method every time it encounters new key. Anyway, it looks like I wouldn't be able to use anything except strings or maybe numbers as keys.
In Java, I would just implement java.util.Map.
Please help me, how would I do the same in Javascript?
edit
I think I will get what I want if I manage to override [[Get]] and [[Put]] methods mentioned here http://interglacial.com/javascript_spec/a-8.html#a-8.6.2.1
For your example, doesn't this do what you want:
var myObj = {};
myObj["two"] = 4;
myObj["four"] = 16;
myObj["twenty one"] = 441;
alert(myObj["four"]); // says 16
Or are you trying to say that the object should magically calculate the squares for you?
JavaScript object keys are strings. If you try to use a number as a key JavaScript basically converts it to a string first.
Having said that, you can use objects as keys if you define a meaningful toString method on them. But of course meaningful is something that happens on a case by case basis and only you will know what needs to be done for your case.
You can also define objects that maintain their own internal data structures which you access via object methods. I think explaining that is beyond the scope of this post. Google "javascript module pattern" for some pointers to get you started.
See http://ejohn.org/blog/javascript-getters-and-setters/
Also this particular answer: Javascript getters and setters for dummies?
edit
According to Does JavaScript have the equivalent of Python's __getattribute__? and Is there an equivalent of the __noSuchMethod__ feature for properties, or a way to implement it in JS? there is no nice way of accomplishing exactly what the OP wants. Getters and setters are not useful because you must know the name of what you're looking for in advance.
My recommendation would thus be to do something like:
var database = {}
database.cache = {}
database.get = function(key) {
// INSERT CUSTOM LOGIC to recognize "forty-two"
if (!(key in database.data))
database.cache[key] = fetch_data_from_database();
return database.cache[key];
}
database.put = function(key, value) {
database.cache[key] = value;
send_data_to_database(key, value);
}
I decided that the most correct way to implement this is to use Harmony:Proxies. It isn't working on all platforms, but it lets implement this in the most seamless way; and it may be supported in more platforms in the future.
This page contains an example that I used as a template to do what I want:
http://wiki.ecmascript.org/doku.php?id=harmony:proxies
I read a few questions and answers about javascript dictionary implementations, but they don't meet my requirements:
the dictionary must be able to take objects as keys
the values must be accessible by the []-operator
So I came up with the idea to overwrite the valueOf-method in Object.prototype, as follows:
Object.__id__ = 0;
Object.prototype.valueOf = function() {
if(!this.__id__)
this.__id__ = ++Object.__id__;
return "__id__" + this.__id__;
}
Object.prototype.toString = Object.prototype.valueOf;
//test
var x = {p1: "5"};
var y = [6];
var z = {};
z[x] = "7";
z[y] = "8";
console.log(z[x], z[y]);
I tested this with google-chrome and it seems to work well, but I'm a bit sceptical, whether this will cause some drawbacks, since it was so easy to implement.
Considering that the valueOf method is not used for other purposes in the whole code, do you think there are any disadvantages?
It's an interesting idea. I suggest my jshashtable. It meets your first requirement but not the second. I don't really see the advantage of insisting on using the square bracket property access notation: do you have a particular requirement for it?
With jshashtable, you can provide a hashing function to the Hashtable constructor. This function is passed an object to be used as a key and must return a string; you could use a function not dissimilar to what you have there, without having to touch Object.prototype.
There are some disadvantages to your idea:
Your valueOf method will show up in a for...in loop over any native object;
You have no way determining which keys should be considered equal, which is something you may want to do. Instead, all keys will be considered unique.
This won't work with host objects (i.e. objects provided by the environment, such as DOM elements)
It is an interesting question, because I had so far assumed that any object can be used as an index (but never tried with associative arrays). I don't know enough about the inner workings of JavaScript to be sure, but I'd bet that valueOf is used somewhere else by JavaScript, even if not in your code. You might run into seemingly inexplicable problems later. At least, I'd restrict myself to a new class and leave Object alone ;) Or, you explicitly call your hashing function, calling it myHash() or whatever and calling z[x.myHash()] which adds clutter but would let me, personally, sleep better ;) I can't resist thinking there's a more JavaScript-aware solution to this, so consider all of these ugly workarounds ;)
If you came upon this question looking for a JS dictionary where objects are keys look at Map Map vs Object in JavaScript
I have selected a control using the following variable
var txt = $("#text1");
Now when I have to handle events on the textbox, do I have to reference it as $(txt) or txt will do
$(txt).keydown(function() {})
or
txt.keydown(function(){})
What is the advantage. Please explain it taking the variable txt as the context.
If txt is already equal to a jquery object, there is no need to use $(txt) as it's just extra processing to return the same thing.
The best approach is to declare your variables so know what they are. Basically, what I'm saying is apply some apps hungarian and prefix your jQuery variables with a $
var $text1 = $("#text1"); // this is a jQuery object
var text1 = $text1[0]; // this is not
A bit more info on Chad's response.
The $() is a short cut to the commonly used function
document.getElementById().
Once you lookup and store the object's value you don't need to look it up again. As Chad mentioned. Ask your self is the variable an object or a name (string), if it's a name you will have to lookup the object.
In my experience I've found that using $(txt) yields more predictable results compared to assigning it as a reference ans using the reference to call the same methods/properties. It's possibly superstition on my part, however a few of us at work have been foiled by using a reference such as txt rather than an implicit $(txt) once txt has been assigned.